Tak, możesz używać SOLR jako bazy danych, ale jest kilka naprawdę poważnych zastrzeżeń:
-
Najpopularniejszy wzorzec dostępu SOLR, który jest przez http, nie reaguje szczególnie dobrze na zapytania wsadowe. Co więcej, SOLR NIE przesyła strumieniowo danych --- więc nie możesz leniwie przeglądać milionów rekordów na raz. Oznacza to, że musisz być bardzo rozważny podczas projektowania wzorców dostępu do danych na dużą skalę za pomocą SOLR.
-
Chociaż wydajność SOLR skaluje się w poziomie (więcej komputerów, więcej rdzeni itp.), a także w pionie (więcej pamięci RAM, lepsze komputery itp.), jego możliwości zapytań są poważnie ograniczone w porównaniu z dojrzałymi RDBMS . To powiedziawszy, istnieje kilka doskonałych funkcji, takich jak zapytania o statystyki pola, które są całkiem wygodne.
-
Deweloperzy przyzwyczajeni do korzystania z relacyjnych baz danych często napotykają problemy, gdy używają tych samych wzorców projektowych DAO w paradygmacie SOLR, ze względu na sposób, w jaki SOLR używa filtrów w zapytaniach. Istnieje krzywa uczenia się umożliwiająca opracowanie odpowiedniego podejścia do tworzenia aplikacji wykorzystującej SOLR do części dużych zapytań lub modyfikacji stanowych .
-
Narzędzia „enterprisy”, które pozwalają na zaawansowane zarządzanie sesjami i encje stanowe, które wiele zaawansowanych platform internetowych (Ruby, Hibernate, ...) będzie musiało zostać całkowicie wyrzuconych przez okno .
-
Relacyjne bazy danych mają za zadanie radzić sobie ze złożonymi danymi i relacjami – dlatego towarzyszą im najnowocześniejsze metryki i zautomatyzowane narzędzia analityczne. W SOLR zauważyłem, że piszę takie narzędzia i często ręcznie przeprowadzam testy warunków skrajnych, co może być stratą czasu .
-
Łączenie:to jest wielki zabójca. Relacyjne bazy danych obsługują metody budowania i optymalizacji widoków oraz zapytań, które łączą krotki na podstawie prostych predykatów. W SOLR nie ma żadnych niezawodnych metod łączenia danych między indeksami.
-
Odporność :W celu zapewnienia wysokiej dostępności SolrCloud wykorzystuje pod spodem rozproszony system plików (tj. HCFS). Ten model jest zupełnie inny niż w przypadku relacyjnej bazy danych, która zwykle zapewnia odporność przy użyciu urządzeń podrzędnych i nadrzędnych, macierzy RAID i tak dalej. Musisz więc być gotowy do zapewnienia infrastruktury odpornościowej wymaganej przez SOLR, jeśli chcesz, aby była skalowalna w chmurze i odporna.
To powiedziawszy - istnieje wiele oczywistych zalet SOLR w przypadku niektórych zadań:(patrz http://wiki. apache.org/solr/WhyUseSolr ) — luźne zapytania są znacznie łatwiejsze do uruchomienia i zwracają sensowne wyniki. Indeksowanie odbywa się domyślnie, więc większość dowolnych zapytań działa dość efektywnie (w przeciwieństwie do RDBMS, gdzie często trzeba optymalizować i denormalizować po fakcie).
Wniosek: Nawet jeśli MOŻESZ używać SOLR jako RDBMS, może się okazać (tak jak ja), że ostatecznie „nie ma darmowego lunchu” – i oszczędności kosztów super-fajnego wyszukiwania tekstowego lucene i wysokiej wydajności indeksowania w pamięci, są często opłacane przez mniejszą elastyczność i przyjęcie nowych przepływów pracy z dostępem do danych.
