abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
eParkomat, startup z ČR, postoupil mezi finalisty evropského akcelerátoru ChallengeUp!
Robot na pivo mu otevřel dveře k opravdovému byznysu
Internet věcí: Propojený svět? Už se to blíží...
včera 16:24 | Nová verze

Byla vydána Mageia 5.1. Jedná se o první opravné vydání verze 5, jež vyšla v červnu loňského roku (zprávička). Uživatelům verze 5 nepřináší opravné vydání nic nového, samozřejmě pokud pravidelně aktualizují. Vydání obsahuje všechny aktualizace za posledního téměř půldruhého roku. Mageia 5.1 obsahuje LibreOffice 4.4.7, Linux 4.4.32, KDE4 4.14.5 nebo GNOME 3.14.3.

Ladislav Hagara | Komentářů: 0
včera 13:42 | Pozvánky

V Praze probíhá konference Internet a Technologie 16.2, volné pokračování jarní konference sdružení CZ.NIC. Konferenci lze sledovat online na YouTube. K dispozici je také archiv předchozích konferencí.

Ladislav Hagara | Komentářů: 0
2.12. 22:44 | Komunita

Joinup informuje, že Mnichov používá open source groupware Kolab. V srpnu byl dokončen dvouletý přechod na toto řešení. V provozu je asi 60 000 poštovních schránek. Nejenom Kolabu se věnoval Georg Greve ve své přednášce Open Source: the future for the European institutions (SlideShare) na konferenci DIGITEC 2016, jež proběhla v úterý 29. listopadu v Bruselu. Videozáznam přednášek z hlavního sálu je ke zhlédnutí na Livestreamu.

Ladislav Hagara | Komentářů: 16
2.12. 15:30 | Zajímavý projekt

Společnost Jolla oznámila v příspěvku Case study: Sailfish Watch na svém blogu, že naportovala Sailfish OS na chytré hodinky. Využila a inspirovala se otevřeným operačním systémem pro chytré hodinky AsteroidOS. Použita je knihovna libhybris. Ukázka ovládání hodinek na YouTube.

Ladislav Hagara | Komentářů: 8
2.12. 14:15 | Nová verze

Byla vydána verze 7.1.0 skriptovacího jazyka PHP používaného zejména k vývoji dynamických webových stránek. Jedná se o první stabilní verzi nejnovější větvě 7.1. Přehled novinek v dokumentaci. Podrobnosti v ChangeLogu. K dispozici je také příručka pro přechod z PHP 7.0.x na PHP 7.1.x.

Ladislav Hagara | Komentářů: 2
2.12. 12:55 | Nová verze

Google Chrome 55 byl prohlášen za stabilní. Nejnovější stabilní verze 55.0.2883.75 tohoto webového prohlížeče přináší řadu oprav a vylepšení (YouTube). Opraveno bylo také 36 bezpečnostních chyb. Mariusz Mlynski si například vydělal 22 500 dolarů za 3 nahlášené chyby (Universal XSS in Blink).

Ladislav Hagara | Komentářů: 4
2.12. 11:55 | Pozvánky

Máte rádi svobodný software a hardware nebo se o nich chcete něco dozvědět? Přijďte na 135. sraz spolku OpenAlt, který se bude konat ve čtvrtek 8. prosince od 18:00 v Radegastovně Perón (Stroupežnického 20, Praha 5). Sraz bude tentokrát tématický. Bude retro! K vidění budou přístroje jako Psion 5mx nebo Palm Z22. Ze svobodného hardwaru pak Openmoko nebo čtečka WikiReader. Přijďte se i vy pochlubit svými legendami, nebo alespoň na pivo. Moderní hardware má vstup samozřejmě také povolen.

xkucf03 | Komentářů: 0
2.12. 00:10 | Nová verze

Byla vydána verze 3.2 svobodného systému pro detekci a prevenci průniků a monitorování bezpečnosti počítačových sítí Suricata. Z novinek lze zmínit například podporu protokolů DNP3 a CIP/ENIP, vylepšenou podporu TLS a samozřejmě také aktualizovanou dokumentaci.

Ladislav Hagara | Komentářů: 0
1.12. 21:00 | Nová verze

Byla vydána beta verze Linux Mintu 18.1 s kódovým jménem Serena. Na blogu Linux Mintu jsou hned dvě oznámení. První o vydání Linux Mintu s prostředím MATE a druhé o vydání Linux Mintu s prostředím Cinnamon. Stejným způsobem jsou rozděleny také poznámky k vydání (MATE, Cinnamon) a přehled novinek s náhledy (MATE, Cinnamon). Linux Mint 18.1 bude podporován až do roku 2021.

Ladislav Hagara | Komentářů: 0
1.12. 16:42 | Nová verze

Byl vydán Devuan Jessie 1.0 Beta 2. Jedná se o druhou beta verzi forku Debianu bez systemd představeného v listopadu 2014 (zprávička). První beta verze byla vydána v dubnu letošního roku (zprávička). Jedna z posledních přednášek věnovaných Devuanu proběhla v listopadu na konferenci FSCONS 2016 (YouTube, pdf).

Ladislav Hagara | Komentářů: 0
Kolik máte dat ve svém domovském adresáři na svém primárním osobním počítači?
 (32%)
 (24%)
 (29%)
 (7%)
 (5%)
 (3%)
Celkem 767 hlasů
 Komentářů: 50, poslední 29.11. 15:50
Rozcestník
Reklama

Dotaz: Jakou databázi...

11.1.2011 23:56 jojol
Jakou databázi...
Přečteno: 720×
Předem se omlouvá za potencionálně trapný dotaz...

Mám hodnoty například: 1025614 1365992 1625430 2113601 2136500 seřazené vzestupně

Celkem těch hodnot je zhruba 3 000 000.

Mno a když zadám například 140020 chci aby mi to vrátilo nejbližší vyšší položku a nejbližší nižší položku tedy 1365992 a 1625430.

Dokázal by mi někdo naznačit jak by se toto řešilo? Jaká databáze/jaký druh databáze by byl pro to vhodný?

Odpovědi

12.1.2011 02:01 Messa | skóre: 39 | blog: Messa
Rozbalit Rozbalit vše Re: Jakou databázi...
Skoro jakákoliv... Na jedné straně můžeš použít něco sofistikovaného, na druhé něco trapně jednoducného. Záleží, co od toho čekáš.

Můžeš třeba čísla uložit do textového souboru, jedno číslo na řádek. Pětiřádkový program v Pythonu nebo i v bashi či awku ti pak bude umět najít nejbližší vyšší/nižší položku. Kdyby bylo zaručeno, že hledané číslo tam bude, stačilo by jen grep -C 1 :-)

Tenhle jednoduchý přístup má ale nevýhody - vyhledávání není nejrychlejší (kdybys potřeboval třeba tisíc vyhledání za sekundu nebo tak nějak). Můžeš ty čísla pak třeba uložit do SQL databáze. Navíc k SQL databázi se dá (pokud to není sqlite) přistupovat po síti.

Taky se dá udělat nějaké speciální řešení - třeba ukládat ty čísla za sebou do souboru v binární podobě (seřazená, což ale už jak říkáš jsou), zase, implementace samotného vyhledávání v takovém souboru v C++ je opět na pět řádků. To by bylo nejspíš nejefektivnější. Ale už to tu nechci dále komplikovat :)

Napiš, jak by sis představoval používání té databáze, ať víme aspoň, jestli to má být stále běžící démon, nebo jednorázová konzolová utilitka, jak to má být rychlé...
12.1.2011 09:04 FooBar
Rozbalit Rozbalit vše Re: Jakou databázi...
"jak by se toto resilo" -- tohle je pripad pro trivialni B-tree, realne nechces nic jinyho. Typickej zastupce pro tohle je BDB, s tim, ze ti sam o sobe neposkytne sitovy rozhrani. Nicmene je to principialne daleko lepsi, nez to cpat do relacni databaze, pac tohle proste nejsou data vhodny do relacni databaze, obtezovat se s overheadem parsovani SQLka, atd. atd.

Messa nahore nadhodil ideu vyhledavat ty hodnoty pres binarni vyhledavani, coz by sice slo, ale tim ze je to nad pomalym diskem, tak to neni tak docela winning strategy (proto ostatne B-tree vznikl). Dalo by se to zlepsit agresivnim aplikacnim cachovanim, ale v ten moment musis resit cache coherency kdyz by ti k tem datum pristupovalo vic instanci... neni to proste az tak trivialni;) Moje doporuceni: BerkeleyDB nad B-Tree, pokud nemas nejaky dodatecny pozadavky ktery jsi opomenul zminit.
12.1.2011 09:31 l4m4
Rozbalit Rozbalit vše Re: Jakou databázi...
ale tim ze je to nad pomalym diskem
Možná jsem něco přehlédl, ale dnes snad není problém mít 3M položek v paměti?
12.1.2011 09:36 FooBar
Rozbalit Rozbalit vše Re: Jakou databázi...
Nene, to rozhodne neni, ale vychazel jsem z toho, ze nerekl skoro nic o tom, jak k tem datum planuje pristupovat. Bude existujici data menit? Mazat? Bude mit konkurencni pristup k datum? Ze to budou data serializovane do pajpy a nasledne z nich bude (zrejme) jen vyhledavat zminil az nasledne v komentari...
12.1.2011 09:39 FooBar
Rozbalit Rozbalit vše Re: Jakou databázi...
Jeste dodam, ze minimalne na unixovejch OS bude (pocitam-li ze uklada 32b inty) tech 12MB velmi pravdepodobne kompletne nacachovany a I/O v ten moment taky nebude takovej bottleneck (a problem s koherenci dat mezi diskem a pameti se presouva pomerne pohodlne na vrstvu ktera je na to daleko lip vybavena).
Heron avatar 12.1.2011 09:15 Heron | skóre: 50 | blog: root_at_heron | Olomouc
Rozbalit Rozbalit vše Re: Jakou databázi...
Dotaz není ani tak trapný, jako zajímavý :-) Jak již napsali předřečníci, na toto se hodí prakticky cokoliv (můžeš si třeba napsat binární vyhledávání v C jako úlohu na víkend; osobně bych to také viděl na BerkleyDB). Co ta čísla znamenají a opravdu budou žít sama o sobě (ve smyslu, bude tam vztah ještě s jinými daty)? Napadá mě použití například v průmyslu jako nalezení nejbližší hodnoty z typové řady, ale toho nebude takový počet.
12.1.2011 09:16 jojol
Rozbalit Rozbalit vše Re: Jakou databázi...
Čísla se stejnou šířkou tedy od 1000000 do 9000000.

Čísla budou řazená vzestupně, ale mezi položkami bude různý rozdíl, tedy někdy 1000000 1000001 10000002, jindy klidně 1001000 1020000 1029000.

Vlastně popravdě rečeno ty čísla budou čas ve formátu YYYYMMDDHHMMSS.

Měl by to být démon, data která se budou zapisovat do databáze bude číst z pojmenované roury. Čas potřebný k vyhledání nebližší polozky by měl být v řádu milisekund.
12.1.2011 09:28 l4m4
Rozbalit Rozbalit vše Re: Jakou databázi...
Je-li strom v paměti, je vlastní vyhledání nanejvýš v řádu mikrosekund.
12.1.2011 11:09 jojol
Rozbalit Rozbalit vše Re: Jakou databázi...
Nene, to rozhodne neni, ale vychazel jsem z toho, ze nerekl skoro nic o tom, jak k tem datum planuje pristupovat. Bude existujici data menit? Mazat? Bude mit konkurencni pristup k datum? Ze to budou data serializovane do pajpy a nasledne z nich bude (zrejme) jen vyhledavat zminil az nasledne v komentari...
ano následně jen vyhledávat nebo mazat...
Je-li strom v paměti, je vlastní vyhledání nanejvýš v řádu mikrosekund.
Data budou na disku, v paměti by zabíraly hodně místa...

Je tu nějaká databáze, která přímo zvládá data vyhledávat tak jak potřebuji, nebo se to bude muset řešit nějak složitěji?
okbob avatar 12.1.2011 11:31 okbob | skóre: 30 | blog: systemakuv_blog | Benešov
Rozbalit Rozbalit vše Re: Jakou databázi...
Všechny db, které znají klauzuli LIMIT to zvládají
SELECT * FROM tab WHERE cislo > konstanta LIMIT 1;
SELECT * FROM tab WHERE cislo < konstanta LIMIT 1;
12.1.2011 14:04 kuka
Rozbalit Rozbalit vše Re: Jakou databázi...
To nenajde nejblizsi mensi cislo ale nejake "nahodne" mensi cislo.
Tarmaq avatar 12.1.2011 16:28 Tarmaq | skóre: 39
Rozbalit Rozbalit vše Re: Jakou databázi...
ne pokud tam bude pridano ORDER BY konstanta
Don't panic!
12.1.2011 16:41 Šangala | skóre: 56 | blog: Dutá Vrba - Wally
Rozbalit Rozbalit vše Re: Jakou databázi...
A pokud se vymění pár písmenek a některé prohodí vypíše to: „pojďme na 1 malé pivo“. :)
To, že trpíš stihomamem, ještě neznamená, že po tobě nejdou. ⰞⰏⰉⰓⰀⰜⰉ ⰗⰞⰅⰜⰘ ⰈⰅⰏⰉ ⰒⰑⰎⰉⰁⰕⰅ ⰏⰉ ⰒⰓⰄⰅⰎ ·:⁖⁘⁙†
Tarmaq avatar 12.1.2011 17:48 Tarmaq | skóre: 39
Rozbalit Rozbalit vše Re: Jakou databázi...
:D tak pojdme, ale tohle stejne nikdy u jednoho maleho piva neskonci ;]
jinak niz jsem napsal cele reseni
Don't panic!
okbob avatar 12.1.2011 18:20 okbob | skóre: 30 | blog: systemakuv_blog | Benešov
Rozbalit Rozbalit vše Re: Jakou databázi...
Pravda chybí tam ORDER BY, sorry
Heron avatar 12.1.2011 11:36 Heron | skóre: 50 | blog: root_at_heron | Olomouc
Rozbalit Rozbalit vše Re: Jakou databázi...
Ach jo. Před chvílí jste psal, že máte pouze čísla, potom se z toho stala časová značka a teď se to najednou nevleze do paměti.

Takže, pokud chcete vyhledávat nejbližší časovou značku provázanou s dalšími údaji, dejte to do relační DB, nad sloupcem časové značky si udělejte index (což je ten B-Strom, který nakonec bude v paměti) a dotazy na to budou velmi rychlé.
12.1.2011 11:44 FooBar
Rozbalit Rozbalit vše Re: Jakou databázi...
Dost bych doporucil, abys prestal davat pozadavky a vlastnosti systemu iterativne a dal to vsechno najednou, jinak budes dostavat reseni na problem kterej vlastne nemas a lidi budes jen srat.

Tri miliony celych cisel v rozsahu "1000000 do 9000000", kdyz z toho udelam 32b int, je 12MB. To je nic. Ale ocividne v tom rozsahu nebudou, kdyz rikas, ze "Vlastně popravdě rečeno ty čísla budou čas ve formátu YYYYMMDDHHMMSS." Pak rikas, ze se to nevejde do pameti. V puvodni otazce rikas, ze chces jen vyhledavat polozky, pak rikas, ze chces i mazat.

Co teda sakra chces?
12.1.2011 12:22 dustin | skóre: 60 | blog: dustin
Rozbalit Rozbalit vše Re: Jakou databázi...
+1
Tarmaq avatar 12.1.2011 16:39 Tarmaq | skóre: 39
Rozbalit Rozbalit vše Re: Jakou databázi...
CREATE TABLE foo (
  id NUMBER(16) PRIMARY KEY
);

INSERT INTO foo VALUES (1025614);
INSERT INTO foo VALUES (1365992);
INSERT INTO foo VALUES (1625430);
INSERT INTO foo VALUES (2113601);
INSERT INTO foo VALUES (2136500);


SELECT id FROM foo WHERE id > 1400200 AND ROWNUM = 1 ORDER BY id ASC;
SELECT id FROM foo WHERE id < 1400200 AND ROWNUM = 1 ORDER BY id DESC;
Tohle funguje na oraclu, na jinych dbms misto toho bude neco jako LIMIT 1 na konci..
Don't panic!
12.1.2011 19:22 jekub
Rozbalit Rozbalit vše Re: Jakou databázi...
tohle funguje na oraclu

ani omylem. nejprve se provede where (id > 1400200 and rownum = 1) a az potom order. cili libovolny radek pro id > 1400200.

kdyz uz, tak
select id from(
   select id from foo where id > 1400200 order by id
) where rownum=1
13.1.2011 10:32 kuka
Rozbalit Rozbalit vše Re: Jakou databázi...
Nefunguje, viz uz prispevek vyse. Pokud by bylo opravdu potreba jen to id, bude z hlediska vykonu podstatne lepsi pouzit min(id)/max(id) misto order by.
Tarmaq avatar 13.1.2011 11:53 Tarmaq | skóre: 39
Rozbalit Rozbalit vše Re: Jakou databázi...
takze tohle by mohlo byt univerzalni reseni ve vsech db:
SELECT MIN(id) FROM foo WHERE id > 1400200;
SELECT MAX(id) FROM foo WHERE id < 1400200;
Don't panic!
13.1.2011 00:05 VM
Rozbalit Rozbalit vše Re: Jakou databázi...
Pole v paměti (pro 32bit čísla zabere 12MB), několikařádkový program v C to půlením intervalu najde v mikrosekundách. Použít databázi je zde kanón na vrabce, navíc by to fungovalo o několik řádů pomaleji.
14.1.2011 02:24 jojol
Rozbalit Rozbalit vše Re: Jakou databázi...
Dost bych doporucil, abys prestal davat pozadavky a vlastnosti systemu iterativne a dal to vsechno najednou, jinak budes dostavat reseni na problem kterej vlastne nemas a lidi budes jen srat.
Ok chci udělat webovou aplikaci pro přehrávání obrázků pořízený programem motion.

Motion obsahuje softwarovou detekci pohybu, takže nebude obrázky ukládat například každou sekundu, ale náhodně.

Plánuji, že se obrázky budou ukládat do adresářový struktury ve formátu YYMMDD/HHMMSS.jpg

Při každém uloženém obrázku motion pustí příkaz "echo 'YYMMDDHHMMSS NAZEV_KAMERY' > named_pype"

No a nějaká aplikace bude z té pojmenované roury číst, a informace o obrázcích ukládat do nějakého vhodného úložiště.

Jo a po zaplnění disku obrázky hodlám staré obrázky mazat, počítám se zhruba 30 dením záznamem - 3600*24*30 = 2592000.

Ve webové aplikaci budu chtít přehrát obrázky od určitého data, tedy bude muset k tomu datu najít nejbližší uložený snímek, dále snímek co je hnedka po něm...

Hodlám to spáchat v jazyce Erlang. Chci to napsat proto, abych tak nějak naučil v Erlangu programovat - tedy jakási cvičná/výuková aplikace.
14.1.2011 09:21 Šangala | skóre: 56 | blog: Dutá Vrba - Wally
Rozbalit Rozbalit vše Re: Jakou databázi...
Za sebe doporučuji jednoznačně libovolnou DB (MySQL plně dostačuje) a udělat tabulky:

camera
cameraid_pk int autoincrement primary
name varchar(64)
description text/textblob/
placement varchar(255)
picture
pictureid_pk bigint autoincrement primary
cameraif_pk_fk int index (foreign key cameraid_pk)
datetaken DATATIME index
filename varchar(1024)
picture2 (lepší)
pictureid_pk bigint autoincrement primary
cameraif_pk_fk int index (foreign key cameraid_pk)
datetaken DATA index
jinak dělení na YYMMDD a HHMMSS je nedostatečné bo tam musí být identifikátor camery:
YYMMDD/HHMMSS_CAMERAID
CAMERAID/YYMMDD/HHMMSS
YYYY/MM/DD/CAMERAID_HHMMSS
(přičemž CAMERAID jsou vždy 4 znaky/čísla - třeba)
To vše za předpokladu, že lze vytvořit max 1 snímek/sec, jinak by tam musely být buď milisecundy, nebo nějaké pořadové číslo a v db by přibyl sloupec addnumber int.

picture2 je lepší v tom, že má pevnou šířku záznamu a cestu získáváte pomocí:
('+' chápejte jako spojování řetězců a fci TIME že vrací opravdu HHMMSS)
YEAR(datetaken) + '/' + LPAD('0',2,MONTH(datetaken)) + '/' + LPAD('0',2,DAY) + '/' + TIME(HHMMSS) + '_' + LPAD('0',4,cameraif_pk_fk).

pak bych přidal tabulku:

checkpoint
cameraid_pk int autoincrement primary
name varchar(64)
cameraif_pk_fk int index (foreign key cameraid_pk)
description text/textblob/

ve které si sloučíte, kamery na jeden objekt (je-li to třeba)
a cesta by mohla být, i když nemusí, přijde na to, jestli má být přímý přístup přehledný nějakým stylem:
CHECKOPOINT/CAMERAID/YYYY/MM/DD/HHMMSS
Výběr nad databází nejbližší vyšší/nižší a pod. je jednoduchá záležitost a tak jak jsem to popsal tak na MySQL i se stovkami milióny záznamů velmi rychlá záležitost.

PS: To, že id-čka nemusí být zlobivé inkrementy, je jasné a záleží jak to chcete.
To, že trpíš stihomamem, ještě neznamená, že po tobě nejdou. ⰞⰏⰉⰓⰀⰜⰉ ⰗⰞⰅⰜⰘ ⰈⰅⰏⰉ ⰒⰑⰎⰉⰁⰕⰅ ⰏⰉ ⰒⰓⰄⰅⰎ ·:⁖⁘⁙†

Založit nové vláknoNahoru

Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

ISSN 1214-1267   www.czech-server.cz
© 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.