Vyšlo Pharo 12.0, programovací jazyk a vývojové prostředí s řadou pokročilých vlastností. Krom tradiční nadílky oprav přináší nový systém správy ladících bodů, nový způsob definice tříd, prostor pro objekty, které nemusí procházet GC a mnoho dalšího.
Microsoft zveřejnil na GitHubu zdrojové kódy MS-DOSu 4.0 pod licencí MIT. Ve stejném repozitáři se nacházejí i před lety zveřejněné zdrojové k kódy MS-DOSu 1.25 a 2.0.
Canonical vydal (email, blog, YouTube) Ubuntu 24.04 LTS Noble Numbat. Přehled novinek v poznámkách k vydání a také příspěvcích na blogu: novinky v desktopu a novinky v bezpečnosti. Vydány byly také oficiální deriváty Edubuntu, Kubuntu, Lubuntu, Ubuntu Budgie, Ubuntu Cinnamon, Ubuntu Kylin, Ubuntu MATE, Ubuntu Studio, Ubuntu Unity a Xubuntu. Jedná se o 10. LTS verzi.
Na YouTube je k dispozici videozáznam z včerejšího Czech Open Source Policy Forum 2024.
Fossil (Wikipedie) byl vydán ve verzi 2.24. Jedná se o distribuovaný systém správy verzí propojený se správou chyb, wiki stránek a blogů s integrovaným webovým rozhraním. Vše běží z jednoho jediného spustitelného souboru a uloženo je v SQLite databázi.
Byla vydána nová stabilní verze 6.7 webového prohlížeče Vivaldi (Wikipedie). Postavena je na Chromiu 124. Přehled novinek i s náhledy v příspěvku na blogu. Vypíchnout lze Spořič paměti (Memory Saver) automaticky hibernující karty, které nebyly nějakou dobu používány nebo vylepšené Odběry (Feed Reader).
OpenJS Foundation, oficiální projekt konsorcia Linux Foundation, oznámila vydání verze 22 otevřeného multiplatformního prostředí pro vývoj a běh síťových aplikací napsaných v JavaScriptu Node.js (Wikipedie). V říjnu se verze 22 stane novou aktivní LTS verzí. Podpora je plánována do dubna 2027.
Byla vydána verze 8.2 open source virtualizační platformy Proxmox VE (Proxmox Virtual Environment, Wikipedie) založené na Debianu. Přehled novinek v poznámkách k vydání a v informačním videu. Zdůrazněn je průvodce migrací hostů z VMware ESXi do Proxmoxu.
R (Wikipedie), programovací jazyk a prostředí určené pro statistickou analýzu dat a jejich grafické zobrazení, bylo vydáno ve verzi 4.4.0. Její kódové jméno je Puppy Cup.
IBM kupuje společnost HashiCorp (Terraform, Packer, Vault, Boundary, Consul, Nomad, Waypoint, Vagrant, …) za 6,4 miliardy dolarů, tj. 35 dolarů za akcii.
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: