2011-09-15 14 views
8

Czy ktoś miał jakiekolwiek doświadczenie z MonetDB? Obecnie mam bazę danych MySQL, która jest zbyt duża, a zapytania stają się zbyt wolne. Zgodnie z paradygmatem zorientowanym na kolumnę, insercje będą wolniejsze (co nie przeszkadza mi wcale), ale odzyskiwanie danych staje się bardzo szybkie. Czy mam szansę na uzyskanie większej wydajności pobierania danych przez przejście na MonetDB? Czy to MonetDB wystarczająco dojrzałe?Czy warto wypróbować MonetDB?

+1

Jakieś porównanie porównujące MonetDB z Hyperdex, Aerospike, DynamoDB, Voldermort, VoltDB lub ExtremeDB? – skan

+0

Zastanawiasz się, czy wypróbowałeś MonetDB? Jeśli wydajność jest dla ciebie dobra? – carfield

Odpowiedz

16

Masz szansę poprawić wydajność swojej aplikacji. Zysk jest jednak w dużej mierze zależny od obciążenia pracą, wielkości bazy danych i sprzętu. MonetDB jest opracowywany/dostrajany zgodnie z dwoma głównymi założeniami:

  1. Twoje obciążenie pracą jest analityczne, tzn. Masz wiele (pogrupowanych) agregacji i tym podobne.
  2. Jeszcze ważniejsze: twój gorący zestaw danych (dane, z którymi faktycznie pracujesz) pasuje do głównej pamięci twojego systemu. MonetDB nie ma własnego menedżera bufora, ale korzysta z systemu operacyjnego do obsługi operacji we/wy dysku. Ponieważ system operacyjny (zwłaszcza system Windows, ale także Linux) czasami jest bardzo głupi, jeśli chodzi o wymianę dysku, co może stać się problemem (zwłaszcza w przypadku złączek, którym zabraknie pamięci).

Jeśli chodzi o dojrzałość, prawdopodobnie istnieje więcej opinii na ten temat niż ludzi zamieszkujących tę planetę. Osobiście uważam, że jest wystarczająco dojrzały, ale jestem członkiem zespołu programistów i dlatego jestem stronniczy. Ale MonetDB to projekt badawczy, więc jeśli masz interesującą aplikację, chcielibyśmy o tym usłyszeć i sprawdzić, czy możemy Ci pomóc.

+0

Niektóre dalszy opis: powiedzmy, że moja tabela ma następujące pola (nazwa, birth_date, social_security_id, drivers_licence_id, annual_income), chcę, aby móc to zrobić: select * from osób gdzie nazwa> "M" i birth_date między DATE1 i DATE2 i roczna wartość od 10 do 100; I chcę mieć możliwość SORTUJ przez którekolwiek z tych pól. Wszystkie te zakresy zabijają wydajność, jeśli stół rośnie naprawdę. Mam przeczucie, że MonetDB nie może wiele pomóc w tym przypadku, ale jeśli jest mała szansa, spróbuję. – martincho

+1

Cóż, powiedziałbym, że zależy to od wielkości twoich wyników pośrednich (tj. Liczby krotek, które kwalifikują się do każdego warunku). Jeśli ich identyfikatory (wewnętrzne 64-bitowe liczby całkowite) pasują do pamięci głównej, powinieneś być w porządku. Jeśli nie, może nadal działać przyzwoicie, jeśli pominiesz 'order by'.Warto zwrócić uwagę na MonetDB, że wszystkie operacje są realizowane bardzo wydajnie, ale wszystkie pośrednie wyniki są zmaterializowane w głównej pamięci (lub potencjalnie na dysku), co może zabić wydajność, jeśli nie masz wystarczającej ilości pamięci RAM. Powiedziałbym, że możesz wypróbować MonetDB. – Holger

+0

"Dopasuj w pamięci RAM" skompresowany lub nieskompresowany? Mam na myśli, czy powinienem mieć pamięć RAM, która pasowałaby do całej zawartości folderu "dbfarm"? (mówi o jednej bazie danych z jednym dużym stołem). Dzięki – GBrian

4

Odpowiedź oczywiście zależy od ładunku, ale moje doświadczenie do tej pory wydaje się wskazywać, że o wszystko jest szybsze niż w MonetDB Widziałem w MySQL. Wyjątkiem byłyby sprzężenia, które nie tylko wydają się powolne, ale wydają się całkowicie nieudolne podczas pipeliningu, więc kończysz na potrzebach gob pamięci do przetwarzania dużych. To znaczy, że moje doświadczenia z połączeniami w MySQL nie były dokładnie takie, więc sądzę, że twoje oczekiwania mogą być niskie. Jeśli naprawdę chcesz dobrej wydajności łączenia, prawdopodobnie poleciłbym SQL Server lub podobne; w przypadku innych zapytań, o których wspominasz w komentarzach uzupełniających, MonetDB powinien być niesamowity.

Na przykład, biorąc pod uwagę tabelę zawierającą około 2 milionów wierszy, udało mi się znaleźć jedną kolumnę (w której było około 800 tysięcy wierszy w tym zakresie) i kolejność według innej kolumny, a ograniczony wynik został przetworzony i zwrócony w 25ms. Wydajność tego typu zapytań wydaje się pogarszać ze skalą, ale to powinno dać ci szansę na to, czego możesz się spodziewać w tej skali.

muszę ostrzec, że optymistyczne Model współbieżności może zrzucić tych, które zostały tylko narażeni na współbieżności pesymistycznym (większość ludzi). Zbadałem go, zanim zastanowię się, dlaczego niektóre z twoich zatwierdzeń zawodzą przy jednoczesnym obciążeniu.

+0

Powiedziałbym, że większość osób zna model OCC, ponieważ większość ORM to robi. Pesymistyczna współbieżność i MVCC z drugiej strony większość ludzi go nie zna (MySQL nie obsługuje go oryginalnie, a większość nie-korporacyjnych aplikacji internetowych jest pozbawionych transakcji, a niektóre ORMS nawet nie obsługują blokowania wiersza/tabeli). –