Często korzystałem z Relational DB i zdecydowałem się na inne dostępne typy.
Ten konkretny produkt wygląda dobrze i obiecująco: http://neo4j.org/
Czy ktoś korzystał z graficznych baz danych? Jakie są zalety i wady z perspektywy użyteczności?
Czy korzystałeś z nich w środowisku produkcyjnym? Jaki wymóg skłonił cię do ich użycia?
Odpowiedzi:
W poprzedniej pracy korzystałem z graficznej bazy danych. Nie używaliśmy neo4j, to była wewnętrzna rzecz zbudowana na bazie Berkeley DB, ale była podobna. Był używany w produkcji (nadal jest).
Powodem, dla którego użyliśmy grafowej bazy danych, było to, że dane przechowywane przez system i operacje, które system wykonywał na danych, były dokładnie słabym punktem relacyjnych baz danych i były dokładnie mocnym punktem grafowych baz danych. System musiał przechowywać kolekcje obiektów, które nie mają ustalonego schematu i są połączone ze sobą relacjami. Aby uzasadnić te dane, system musiał wykonać wiele operacji, które byłyby kilkoma przechodzeniami w bazie danych wykresów, ale byłyby to dość złożone zapytania w języku SQL.
Głównymi zaletami modelu wykresu był szybki czas rozwoju i elastyczność. Mogliśmy szybko dodać nowe funkcje bez wpływu na istniejące wdrożenia. Gdyby potencjalny klient chciał zaimportować własne dane i przeszczepić je na nasz model, zwykle mógłby to zrobić na miejscu przedstawiciel handlowy. Elastyczność pomogła również podczas projektowania nowej funkcji, chroniąc nas przed próbami wtłaczania nowych danych do sztywnego modelu danych.
Posiadanie dziwnej bazy danych pozwoliło nam zbudować wiele innych naszych dziwnych technologii, dając nam wiele sekretów, aby odróżnić nasz produkt od produktów konkurencji.
Główną wadą było to, że nie korzystaliśmy ze standardowej technologii relacyjnych baz danych, co może stanowić problem, gdy Twoi klienci są przedsiębiorczy. Nasi klienci pytaliby, dlaczego nie możemy po prostu hostować naszych danych w ich gigantycznych klastrach Oracle (nasi klienci zwykle mają duże centra danych). Jeden z członków zespołu faktycznie przepisał warstwę bazy danych, aby korzystała z Oracle (lub PostgreSQL lub MySQL), ale była nieco wolniejsza niż oryginał. Co najmniej jedno duże przedsiębiorstwo miało nawet politykę dotyczącą wyłącznie Oracle, ale na szczęście Oracle kupiło Berkeley DB. Musieliśmy także napisać wiele dodatkowych narzędzi - nie mogliśmy na przykład po prostu używać Crystal Reports.
Inną wadą naszej bazy danych grafów było to, że sami ją zbudowaliśmy, co oznaczało, że kiedy napotkaliśmy problem (zwykle ze skalowalnością), musieliśmy go rozwiązać samodzielnie. Gdybyśmy użyli relacyjnej bazy danych, sprzedawca rozwiązałby problem już dziesięć lat temu.
Jeśli tworzysz produkt dla klientów korporacyjnych, a Twoje dane pasują do modelu relacyjnego, jeśli możesz, użyj relacyjnej bazy danych. Jeśli Twoja aplikacja nie pasuje do modelu relacyjnego, ale pasuje do modelu wykresu, użyj bazy danych wykresów. Jeśli pasuje tylko do czegoś innego, użyj tego.
Jeśli Twoja aplikacja nie musi pasować do obecnej architektury blub, użyj graficznej bazy danych, CouchDB, BigTable lub czegokolwiek, co pasuje do Twojej aplikacji i uważasz, że jest fajne. Może dać ci przewagę i fajnie jest próbować nowych rzeczy.
Cokolwiek wybierzesz, staraj się nie budować silnika bazy danych samodzielnie, chyba że naprawdę lubisz budować silniki bazy danych.
Pracujemy z zespołem Neo od ponad roku i jesteśmy bardzo szczęśliwi. Modelujemy artefakty naukowe i ich relacje, co jest na miejscu dla bazy danych wykresu, i uruchamiamy algorytmy rekomendacji w sieci.
Jeśli już pracujesz w Javie, myślę, że modelowanie przy użyciu Neo4j jest bardzo proste i ma najbardziej płaską / najszybszą wydajność dla R / W spośród wszystkich innych wypróbowanych przez nas rozwiązań.
Szczerze mówiąc, ciężko jest mi nie myśleć w kategoriach wykresu / sieci, ponieważ jest to o wiele łatwiejsze niż projektowanie zawiłych struktur tabel do przechowywania właściwości i relacji obiektów.
Mając to na uwadze, przechowujemy pewne informacje w MySQL po prostu dlatego, że stronie biznesowej łatwiej jest uruchamiać szybkie zapytania SQL. Aby wykonać te same funkcje z Neo, musielibyśmy napisać kod, na który po prostu nie mamy teraz wystarczającej przepustowości. Jak tylko to zrobimy, przenoszę wszystkie te dane do Neo!
Powodzenia.
Dwa punkty:
Po pierwsze, na danych, z którymi pracowałem przez ostatnie 5 lat w SQL Server, niedawno trafiłem na ścianę skalowalności z SQL dla typów zapytań, które musimy uruchamiać (zagnieżdżone relacje ... wiesz ... wykresy ). Bawiłem się neo4j i moje czasy wyszukiwania są o kilka rzędów wielkości szybsze, gdy potrzebuję tego rodzaju wyszukiwania.
Po drugie, do tego stopnia, że graficzne bazy danych są przestarzałe. Yyy ... nie. Na początku, gdy ludzie próbowali dowiedzieć się, jak efektywnie przechowywać i wyszukiwać dane, tworzyli i bawili się modelami baz danych w stylu wykresów i sieci. Zostały one zaprojektowane tak, aby model fizyczny odzwierciedlał model logiczny, więc ich wydajność nie była tak duża. Ten typ struktury danych był dobry w przypadku danych częściowo ustrukturyzowanych, ale nie był tak dobry w przypadku gęstych danych strukturalnych. Tak więc ten gość z IBM o imieniu Codd badał efektywne sposoby porządkowania i przechowywania ustrukturyzowanych danych i wpadł na pomysł stworzenia modelu relacyjnej bazy danych. I było dobrze, a ludzie byli szczęśliwi.
Co my tu mamy? Dwa narzędzia do dwóch różnych celów. Grafowe modele baz danych są bardzo dobre do reprezentowania danych częściowo ustrukturyzowanych i relacji między jednostkami (które mogą istnieć lub nie). Relacyjne bazy danych są dobre dla danych ustrukturyzowanych, które mają bardzo statyczny schemat i gdzie głębokości złączeń nie są zbyt głębokie. Jedna jest dobra dla jednego rodzaju danych, druga jest dobra dla innych rodzajów danych.
Aby wymyślić to zdanie, nie ma Srebrnej Kuli. Bardzo krótkowzroczne jest stwierdzenie, że modele baz danych wykresów są nieaktualne, a korzystanie z nich oznacza 40 lat postępu. To tak, jakby powiedzieć, że używanie C oznacza rezygnację z całego postępu technologicznego, przez który przeszliśmy, aby uzyskać takie rzeczy, jak Java i C #. To nie jest prawda. C to narzędzie potrzebne do niektórych zadań. A Java to narzędzie do innych zadań.
Używam MySQL od lat do zarządzania danymi inżynieryjnymi i działa dobrze, ale jednym z problemów, które mieliśmy (ale nie zdawaliśmy sobie sprawy, że mamy) było to, że zawsze musieliśmy zaplanować schemat z góry. Innym problemem, o którym wiedzieliśmy, było mapowanie danych do obiektów domeny iz powrotem.
Teraz właśnie zaczęliśmy wypróbowywać neo4j i wygląda na to, że rozwiązuje on oba problemy. Możliwość dodawania różnych właściwości do każdego węzła (i relacji) pozwoliła nam przemyśleć całe nasze podejście do danych. To jest jak języki dynamiczne kontra statyczne (Ruby kontra Java), ale dla baz danych. Budowanie modelu danych w bazie danych może odbywać się w znacznie bardziej zwinny i dynamiczny sposób, co znacznie upraszcza nasz kod.
A ponieważ model obiektowy w kodzie jest ogólnie strukturą grafową, mapowanie z bazy danych jest również prostsze, zawiera mniej kodu, a co za tym idzie mniej błędów.
Jako dodatkowy bonus, nasz początkowy kod prototypowy do ładowania naszych danych do neo4j działa szybciej niż poprzednia wersja MySQL. Nie mam stałych liczb na ten temat (jeszcze), ale to była fajna dodatkowa funkcja.
Ostatecznie jednak wybór prawdopodobnie powinien opierać się głównie na naturze modelu domeny. Czy lepiej odwzorowuje tabele lub wykresy? Zdecyduj, wykonując prototypy, załaduj dane i baw się nimi. Użyj neoclipse, aby przyjrzeć się różnym widokom danych. Gdy już to zrobisz, miejmy nadzieję, że wiesz, czy masz coś dobrego, czy nie.
Buduję intranet w mojej firmie.
Interesuje mnie zrozumienie, jak ładować dane, które były przechowywane w tabelach (Oracle, MySQL, SQL Server, Excel, Access, różne listy losowe) i ładować je do Neo4J lub innej bazy danych grafów. W szczególności, co się dzieje, gdy wspólne dane nakładają się na istniejące już w systemie.
Tak, wiem, że niektóre dane najlepiej modeluje się w RDBMS, ale drażni mnie ten pomysł, że kiedy trzeba nałożyć kilka różnych tabel, model wykresu jest lepszy niż struktura tabeli.
Na przykład pracuję w środowisku produkcyjnym. Istnieje duży projekt, nad którym pracujemy i ze względu na złożoność, każdy dział utworzył oddzielny arkusz kalkulacyjny Excel, który ma hierarchię BOM (zestawienie komponentów) w kolumnie po lewej stronie, a następnie kilka kolumn notatek i kontroli wykonanych przez poszczególne osoby kto zrobił te arkusze.
Tak więc jednym z problemów jest połączenie wszystkich tych notatek w jeden „widok”, aby ktoś mógł zobaczyć wszystkie kwestie, które należy rozwiązać w określonej części.
Drugi problem polega na tym, że arkusz kalkulacyjny programu Excel nie radzi sobie z przedstawieniem hierarchicznej LM, gdy wspólny komponent jest używany w więcej niż jednym podzespole. Czyli jeśli ktoś napisze notatkę o przekaźniku P34 w podzespole zapłonu to ten sam komentarz należy skojarzyć z przekaźnikami P34 zastosowanymi w podzespole sterownika silnika. Nie wystąpi to w arkuszu kalkulacyjnym programu Excel.
W intranecie firmowym chcę mieć możliwość łatwego wyszukiwania wszystkiego. Takie jak dane związane z numerem części, strukturą BOM, numerem telefonu, adresem e-mail, polityką firmy lub procedurą. Chcę nawet rozszerzyć to, aby zarządzać zasobami sprzętu komputerowego i zainstalowanym oprogramowaniem.
Wyobrażam sobie, że kiedy sieć informacyjna zacznie się zapełniać, można zacząć robić fajne przemierzania, takie jak „Chcę napisać e-maila do wszystkich pracujących nad projektem XYZ”. Osoby zostaną skojarzone z projektem, ponieważ zostaną otagowane jako osoby tworzące i modyfikujące dane w projekcie XYZ. Więc używając projektu XYZ jako klucza wyszukiwania, zostanie utworzony ogromny zestaw zawierający wszystko, co jest związane z projektem XYZ. Zawiera linki do osób, które zbudowały projekt XYZ. Linki osób będą łączyć się z ich adresami e-mail. Tak więc przez ich zaangażowanie w projekt XYZ zostaną uwzględnieni w moim e-mailu. Jest to wyraźne przeciwieństwo sytuacji, w której sekretarz próbuje prowadzić listę osób pracujących nad projektem. Generujemy wiele list. Spędzamy dużo czasu na utrzymywaniu list i upewnianiu się, że są one aktualne.
Kolejne fajne przeglądanie może raportować wszystkie komputery, na których jest zainstalowane określone oprogramowanie, według wersji. Ten raport może zostać użyty do wygenerowania zadań w celu usunięcia dodatkowych kopii starego oprogramowania i zaktualizowania osób, które muszą mieć najnowszą kopię. Byłoby również przydatne do śledzenia licencji.
Oto dobry artykuł, który mówi o potrzebach, które wypełniają nierelacyjne bazy danych: http://www.readwriteweb.com/enterprise/2009/02/is-the-relational-database-doomed.php
Robi dobrą robotę, wskazując (poza nazwą), że relacyjne bazy danych nie są wadliwe ani błędne, po prostu w dzisiejszych czasach ludzie zaczynają przetwarzać coraz więcej danych w głównym oprogramowaniu i witrynach internetowych, a relacyjne bazy danych po prostu nie będą skalowane dla tych potrzeb.
może być trochę spóźniony, ale rośnie liczba projektów wykorzystujących Neo4j, te bardziej znane są wymienione na Neo4j . Również NeoTechnology, firma stojąca za Neo4j, ma kilka odniesień na stronie swoich klientów
Uwaga: jestem częścią zespołu Neo4j