O víkendu (15:00 až 23:00) probíhá EmacsConf 2023, tj. online konference vývojářů a uživatelů editoru GNU Emacs. Sledovat ji lze na stránkách konference. Záznamy jsou k dispozici přímo z programu.
Na čem aktuálně pracují vývojáři GNOME a KDE? Pravidelný přehled novinek i s náhledy aplikací v Týden v GNOME a Týden v KDE.
Organizace Apache Software Foundation (ASF) vydala verzi 20 integrovaného vývojového prostředí a vývojové platformy napsané v Javě NetBeans (Wikipedie). Přehled novinek na GitHubu. Instalovat lze také ze Snapcraftu a Flathubu.
Desktopové prostředí Cinnamon, vyvíjené primárně pro distribuci Linux Mint, dospělo do verze 6.0. Seznam změn obsahuje především menší opravy a v říjnovém přehledu novinek v Mintu avizovanou experimentální podporu Waylandu.
OpenZFS (Wikipedie), tj. implementace souborového systému ZFS pro Linux a FreeBSD, byl vydán ve verzích 2.2.2 a 2.1.14. Přináší důležitou opravu chyby vedoucí k možnému poškození dat.
V ownCloudu byly nalezeny tři kritické zranitelnosti: CVE-2023-49103, CVE-2023-49104 a CVE-2023-49105 s CVSS 10.0, 8.7 a 9.8. Zranitelnost CVE-2023-49103 je právě využívána útočníky. Nextcloudu se zranitelnosti netýkají.
I letos vychází řada ajťáckých adventních kalendářů. Programátoři se mohou potrápit při řešení úloh z kalendáře Advent of Code 2023. Pro programátory v Perlu je určen Perl Advent Calendar 2023. Zájemci o UX mohou sledovat Lean UXmas 2023. Pro zájemce o kybernetickou bezpečnost je určen Advent of Cyber 2023…
Byla vydána verze 2.12 svobodného video editoru Flowblade (GitHub, Wikipedie). Přehled novinek v poznámkách k vydání. Videoukázky funkcí Flowblade na Vimeu. Instalovat lze také z Flathubu.
Armbian, tj. linuxová distribuce založená na Debianu a Ubuntu optimalizovaná pro jednodeskové počítače na platformě ARM a RISC-V, ke stažení ale také pro Intel a AMD, byl vydán ve verzi 23.11 Topi. Přehled novinek v Changelogu.
Po 4 měsících vývoje byla vydána nová verze 4.2 multiplatformního open source herního enginu Godot (Wikipedie, GitHub). Přehled novinek i s náhledy v příspěvku na blogu a na YouTube.
phone - phoneservice
0207xxxxxxx - 0207xxxxxxx@customername.sip.ourdomain.net
0207yyyyyyy - 0207yyyyyyy@othercustomer.sip.ourdomain.net
.
.
.
.
celkovo ma 4 miliony riadkov a je to databaza aliasov pre OpenSER.
mam nasledovne poziadavky:
- databaza musi zvladnut az 30 000 READS behom jednej sekundy
- co sa tyka updatov, tie budu velmi zriedkave, na tie nemam ziadne poziadavky
a teraz otazky:
Zvladne toto MySQL s InnoDB? nemal by som radsej pouzit nejaku BerkeleyDB?
pobezi to na 4 jadrovom Xeone, 16GB RAM. RAID-5 uscsi 320. Viem ze to budem musiet aj otestovat, teda neocakavam odpoved po ktorej sa do toho vrhnem, staci nasmerovanie od ludi so skusenostami.
Použil bych klidně MySQL ale s MyISAM, protože dle dostupných informací je MyISAM při takovýchto tabulkách mnohem rychlejší. Vlastnosti, který přináší InnoDB oproti MyISAM (např. transakce) při plánovaném využití nepotřebuješ.
BerkleyDB (db4) - 0.699s memcached - 2.585s MySQL (MyISAM) - 7.124s sqlite - 20.448s PostgreSQL - 96.241sZ môjho pohľadu veľmi príjemne prekvapil db4 a MySQL, naopak Postgres a memcache boli značným sklamaním.
BerkleyDB (db4) - 0.494s sqlite - 1.537s MySQL (MyISAM) - 2.002s PostgreSQL - 4.997s memcached - masked pre 64bit, t.j. netestovanéT.j. nie až taký debakel, aj keď postgres z toho aj tak zvlášť dobre nevychádza. Na druhej strane, používame ho a ceníme si ho nie preto, že vie slúžiť ako rýchla hash-tabuľka, ale preto, že má aj nejaké tie funkcie naviac...
araxon=# \d speed_test Table "public.speed_test" Column | Type | Modifiers --------+-------------------+----------- num | character(7) | not null val | character varying | not null Indexes: "speed_test_pkey" PRIMARY KEY, btree (num)Po inserte všetkých riadkov som ešte spravil VACUUM ANALYZE. Problém bol asi v tom, že súbor s databázou a indexom bol väčší než voľná RAM a tak sa do diskovej cache celý nezmestil - narozdiel od všetkých ostatných DB čo som skúšal. Je pravda, že miesto char som mohol použiť radšej numeric, ale char som použil aj vo všetkých ostatných DB...
MySQL (MyISAM) - 7.124s MySQL (InnoDB) - 9.293sRozdiel nijak zvlášť veľký... ale trvalo mi hodnú chvíľu, kým som to na InnoDB vôbec rozbehol. Defaultne je to nastavené tak, že InnoDB zaberá max. 128M a riadky, ktoré sa tam nezmestia majú proste smolu. Navyše pri OPTIMIZE TABLE to potrebuje ďalší priestor, lebo inak optimize zlyhá a rýchlosť výberu je potom nič moc. A ešte pri insertovaní v rámci transakcie som pozeral z druhej transakcie na počet riadkov, a ten sa priebežne menil - to by som nenazýval "transaction isolation". V postgrese toto chodilo predvídateľnejšie - kým som nedal commit, tak som videl počet riadkov nula...
pri insertovaní v rámci transakcie som pozeral z druhej transakcie na počet riadkov, a ten sa priebežne menil - to by som nenazýval "transaction isolation"Tak buďto to nebyla transakce (autocommit), nebo jste měl isolation level nastavený na read uncommitted, to se stává i v lepších rodinách
Tiskni
Sdílej: