GoldenLine
Zaloguj się

konto usunięte

Temat: Wybór bazy, tips & tricks

Hejka
Ma dosyć specyficzny problem z bazą danych - szukam najlepszej do mojego zadania :) a na serio to może ktoś mi coś poleci:
-> do pięciu procesów zapisuje i czyta jedną bazę,
-> nie ma updatowania wierszy tylko insert i select,
-> procesy wrzucają sporą ilość danych (łącznie baza będzie liczona w gigabajtach)
-> baza ma określone klucze główne i obce, ale są one wyłączone ze względu na szybkość zapisu.
-> select-y jeśli już są to bez joinów itp, tylko proste wyszukiwanie.

Na razie stanęło na postgresie ale z chęcią wysłucham wszelkich rad. Ciekawi mnie też co można by ustawić/pozmieniać aby przyśpieszyć możliwość insertów przy jednoczesnym zachowaniu wielowątkowości zapisu. Ciekawi mnie też czy istnieje jakaś powszechnie znany optymalny rozmiar paczki wierszy dla takiego insertu :)
Link do wypowiedziLink

konto usunięte

Temat: Wybór bazy, tips & tricks

Zapewne wystarczy przetestować sobie różne wersje konfiguracji Postgresa, przełączenie niektórych parametrów mogłoby dać kolosalne zmiany w wydajności... albo i nie, jak to zwykle przy bazach: to zależy. Natomiast nie odrzucałbym ani trochę Postgresa.

Tak naprawdę wszystko zależy od charakterystyki używania bazy, a do tego baza będzie niewielka (bo te gigabajty to w sumie niewiele).

Poza tym same gigabajty nie oznaczają, że aplikacja będzie szybka/wolna.
Można dla bazy o rozmiarze 100MB dać takie zapytanie, że wszystko będzie kosmicznie wolne, a można też mieć i bazę 100GB i bardzo szybkie zapytania.

A skoro będzie tam tylko proste wyszukiwanie, to dla takich prostych wyszukiwań jeszcze nie widziałem bazy i aplikacji, których nie dało się przyspieszyć znaaacznie poprzez odpowiednie zapytania i indeksy. Ale indeksy i postać zapytań zależą bardzo od konkretnych wymagań aplikacji, więc to wyjdzie w praniu jak już całość będzie działać.
Link do wypowiedziLink

konto usunięte

Temat: Wybór bazy, tips & tricks

Jeśli wyłączacie indeksy to znaczy że ładujecie k = więcej niż 1 rekord naraz do bazy.

Jeśli k jest duże (powiedzmy pow. 10 tys) to można zainteresować się hasłem "bulk load" / "bulk insert" np.:

http://www.wikihow.com/Improve-Bulk-Load-Performance-i...

http://www.postgresql.org/docs/8.1/static/sql-copy.html

http://stackoverflow.com/questions/758945/whats-the-fa...

http://pgbulkload.projects.postgresql.org/
Link do wypowiedziLink
Robert Suski

Robert Suski Sr Solutions
Developer

Temat: Wybór bazy, tips & tricks

A może jakaś baza NoSQL?

Chociaż jeśli to jest baza istniejąca już to pewnie nie ma sensu się przesiadać.Robert Suski edytował(a) ten post dnia 26.04.11 o godzinie 22:29
Link do wypowiedziLink
Adam O.

Adam O. Bazy danych etc

Temat: Wybór bazy, tips & tricks

Jak to jest w gigabajtach, to może solidDB?
Link do wypowiedziLink
Michał Gruchała

Michał Gruchała Skalowalność,
wydajność,
niezawodność

Temat: Wybór bazy, tips & tricks

Jeśli jest w goigabajtach to imo "cokolwiek" :)

Generalnie wychodzi, ze operacje sa bardzo proste (takie jakby noSQL'owe).

Wybrałbym to, co jest znane przez autora wątku (lub jego DBA). Moim zdaniem wszystko da rade.
Link do wypowiedziLink

konto usunięte

Temat: Wybór bazy, tips & tricks

Zgadzam się z Michałem. Do GB danych to każda baza uciągnie (chyba,że jest słabo zaprojektowana, nie ma indeksów itp.). Do grubszego przetwarzania to http://cassandra.apache.org/ (noSQL).
Link do wypowiedziLink
Łukasz Dudek

Łukasz Dudek Database
Administrator

Temat: Wybór bazy, tips & tricks

skoro klucze sa powylaczane to niepotrzebnie pakujesz to w relacyjną baze. A już zwłaszcza taką która ma hardcoded ACID.
bulk copy jest połowicznym rozwiązaniem bo nadal masz acid który ci nawet przeszkadza w tym wypadku.
Rozwiązań jest kilka zależy od charakterystyki danych, bo to może zmienić diametralnie podejście do problemu.Łukasz Dudek edytował(a) ten post dnia 27.04.11 o godzinie 20:03
Link do wypowiedziLink
Michał Gruchała

Michał Gruchała Skalowalność,
wydajność,
niezawodność

Temat: Wybór bazy, tips & tricks

Nie pchajcie prosze autora w kierunku rozwiazan, ktorych nie potrzebuje.
Zaraz ktos wyskoczy z shardowaniem ;)
Panowie, kilka GB danych! To uciągnie każda baza, na bylejakim sprzęcie.
Jak baza jest źle zaprojektowana to i mocny sprzęt nie da rady - o tak :D
Link do wypowiedziLink
Michał Gruchała

Michał Gruchała Skalowalność,
wydajność,
niezawodność

Temat: Wybór bazy, tips & tricks

Tomasz Grabiński:
Hejka
Ma dosyć specyficzny problem z bazą danych - szukam najlepszej do mojego zadania :) a na serio to może ktoś mi coś poleci:
-> do pięciu procesów zapisuje i czyta jedną bazę,
-> nie ma updatowania wierszy tylko insert i select,
-> procesy wrzucają sporą ilość danych (łącznie baza będzie liczona w gigabajtach)

to znaczy ile?
Ile na sekunde?
-> baza ma określone klucze główne i obce, ale są one wyłączone ze względu na szybkość zapisu.
-> select-y jeśli już są to bez joinów itp, tylko proste wyszukiwanie.

po kluczu? Jak często są selectowane dane?
Na razie stanęło na postgresie ale z chęcią wysłucham wszelkich rad. Ciekawi mnie też co można by ustawić/pozmieniać aby przyśpieszyć możliwość insertów przy jednoczesnym zachowaniu wielowątkowości zapisu. Ciekawi mnie też czy istnieje jakaś powszechnie znany optymalny rozmiar paczki wierszy dla takiego insertu :)

użyj MySQL i już ;)
Jeśli dane nie będą zmieniane to pasuje engine archive
Link do wypowiedziLink
Daniel Podlejski

Daniel Podlejski DBA,
SysAdmin/DevOps,
backend developer

Temat: Wybór bazy, tips & tricks

Postgres jest w tym wypadku dobrym rozwiązaniem. Będziesz musiał dobrać wartości checkpoint_segments, checkpoint_completion_target i checkpoint_timeout do dysków jakie masz. W przypadku problemów z wydajnością IO masz dwie opcje - sprzętowy kontroler z RAID z write-cache podtrzymywanym bateryjnie albo dyski SSD w mirrorze - ta druga opcja powinna się w tym konkretnym przypadku bardzo dobrze sprawdzić (insert + select, brak updateów).
Link do wypowiedziLink

konto usunięte

Temat: Wybór bazy, tips & tricks

heja

dla parę gb danych - to nie ma co NoSql zaprzęgać - pamiętacie jak to szlo, o kombajnach i kłosach : )

PG da rade.

Od siebie do kolekcji rozwiązać dorzucę jeszcze VoltDB - jest sporo szybsza niż większość podanych RDBMS'ow.

pzdr
Ł
Link do wypowiedziLink

konto usunięte

Temat: Wybór bazy, tips & tricks

Łukasz Grabowski:
heja

dla parę gb danych - to nie ma co NoSql zaprzęgać - pamiętacie jak to szlo, o kombajnach i kłosach : )

Ja mam takie pytanie trochę poza tematem: znacie jakieś testy rozwiązań NoSQL porównanie z SQL, kiedy warto je stosować i dlaczego?
Link do wypowiedziLink

konto usunięte

Temat: Wybór bazy, tips & tricks

Tomek P.:
Łukasz Grabowski:
heja

dla parę gb danych - to nie ma co NoSql zaprzęgać - pamiętacie jak to szlo, o kombajnach i kłosach : )

Ja mam takie pytanie trochę poza tematem: znacie jakieś testy rozwiązań NoSQL porównanie z SQL, kiedy warto je stosować i dlaczego?

Ciekawe pytanie.

Zalety NoSQL to przede wszystkim:
- możliwość zapisywania rekordów, które bardzo różnią się listą wypełnionych pól i wypełnianie ich wartościami NULL było by marnotrastwem
- łatwość skalowania na kilka maszyn

Kiedy je stosować tu masz napisane:
http://www.cfobjective.com/cfo/assets/File/pdfs/JohnPa...

Inne źródła w tym temacie:
http://sqlserverpedia.com/blog/sql-server-bloggers/fiv...
http://nosql.mypopescu.com/post/398352022/recipes-for-...
http://www.couchbase.com/why-nosql/use-cases
http://architects.dzone.com/articles/what-nosql-store-...
http://www.ibm.com/developerworks/java/library/j-javad...-Piotr Likus edytował(a) ten post dnia 28.04.11 o godzinie 16:06
Link do wypowiedziLink
Mariusz Sucajtys

Mariusz Sucajtys Wszyscy wiedzą, że
czegoś nie da się
zrobić, aż znajdzie
...

Temat: Wybór bazy, tips & tricks

Tomek P.:
Ja mam takie pytanie trochę poza tematem: znacie jakieś testy rozwiązań NoSQL porównanie z SQL, kiedy warto je stosować i dlaczego?

Może nie testy, ale jest dokument kategoryzujący produkty oraz opisujący różnice.
BTW: NoSQL wcale nie musi oznaczać automatycznego skalowania przy dodawaniu node'ów.Mariusz Sucajtys edytował(a) ten post dnia 30.04.11 o godzinie 18:21
Link do wypowiedziLink
Mariusz Sucajtys

Mariusz Sucajtys Wszyscy wiedzą, że
czegoś nie da się
zrobić, aż znajdzie
...

Temat: Wybór bazy, tips & tricks

Tomasz Grabiński:
Na razie stanęło na postgresie ale z chęcią wysłucham wszelkich rad. Ciekawi mnie też co można by ustawić/pozmieniać aby przyśpieszyć możliwość insertów przy jednoczesnym zachowaniu wielowątkowości zapisu.

Kilka GB danych to nie jest znowu tak dużo. PostgreSQL i inne RDBMS powinny sobie z tym poradzić. W zależności od maszyny, odpowiednio skonfigurowany RDBMS powinien przechowywać całą bazę w cache.

Nikt nie wspomniał o partycjonowaniu. Ułatwia to retencję danych, może też podnieść wydajność niektórych typów zapytań (w zależności od kryterium zapytania oraz sposobu partycjonowania).

Z tego, co pisałeś, nie wykorzystujesz relacyjności. Zastanów się więc, czy tak naprawdę potrzebujesz bazy danych. Na pewno łatwiej jest napisać i utrzymywać/modyfikować aplikację z wykorzystaniem DB, niż programować własny mechanizm zapisu i odczytu plików w określonej strukturze.

Jakie korzyści odnosisz z zastosowania bazy danych?
Czy korzyści te równoważą czas potrzebny na załadowanie danych do bazy?
Czy mogą to być po prostu pliki na dysku? Wielowątkowość zapisu i odczytu możesz uzyskać, tworząc proces "nasłuchujący" dane z innych procesów i zapisujący je w określonej strukturze.

W jaki sposób dobierasz się do danych? Czy jest to dostęp sekwencyjny, czy losowy?

Wytaczanie rozwiązań NoSQL to w wielu przypadkach może być strzelanie z armaty do wróbli. Wcale nie musi być szybciej, a może być wolniej. Wiele z tych rozwiązań pozwala wykonywać jedynie zapytania po kluczu głównym bez możliwości filtrowania po kluczach obcych.
Link do wypowiedziLink
« Wróć do tematów
Odpowiedz

Podobne tematy





Wyślij zaproszenie do
Anuluj