Да, можете да използвате SOLR като база данни, но има някои наистина сериозни предупреждения:
-
Най-често срещаният модел за достъп на SOLR, който е над http, не реагира особено добре на групово запитване. Освен това, SOLR НЕ предава поточно данни --- така че не можете мързеливо да преглеждате милиони записи наведнъж. Това означава, че трябва да сте много внимателни, когато проектирате широкомащабни модели за достъп до данни с SOLR.
-
Въпреки че производителността на SOLR се мащабира хоризонтално (повече машини, повече ядра и т.н..), както и вертикално (повече RAM, по-добри машини и т.н.), възможностите му за заявки са силно ограничени в сравнение с тези на зряла RDBMS . Въпреки това има някои отлични функции, като заявките за статистика на полето, които са доста удобни.
-
Разработчиците, които са свикнали да използват релационни бази данни, често се сблъскват с проблеми, когато използват едни и същи модели на дизайн на DAO в SOLR парадигма, поради начина, по който SOLR използва филтри в заявките. Ще има крива на обучение за разработване на правилния подход за изграждане на приложение, което използва SOLR за част от своите големи заявки или модификации с пълно състояние .
-
Инструментите за "предприятие", които позволяват разширено управление на сесиите и обекти с пълно състояние, които предлагат много напреднали уеб рамки (Ruby, Hibernate, ...), ще трябва да бъдат изхвърлени напълно през прозореца .
-
Релационните бази данни са предназначени да се справят със сложни данни и връзки - и по този начин те са придружени от най-съвременни показатели и автоматизирани инструменти за анализ. В SOLR открих, че пиша такива инструменти и много ръчно тествам стрес, което може да бъде потъване на времето .
-
Присъединяване:това е големият убиец. Релационните бази данни поддържат методи за изграждане и оптимизиране на изгледи и заявки, които обединяват кортежи въз основа на прости предикати. В SOLR няма надеждни методи за обединяване на данни между индекси.
-
Устойчивост:За висока наличност, SolrCloud използва разпределена файлова система отдолу (т.е. HCFS). Този модел е доста по-различен от този на релационна база данни, която обикновено прави устойчивост, използвайки подчинени и главни устройства или RAID и т.н. Така че трябва да сте готови да предоставите инфраструктурата за устойчивост, която SOLR изисква, ако искате тя да бъде мащабируема в облака и устойчива.
Това каза – има много очевидни предимства за SOLR за определени задачи:(вижте http://wiki. apache.org/solr/WhyUseSolr ) -- свободните заявки са много по-лесни за изпълнение и връщат смислени резултати. Индексирането се извършва по подразбиране, така че повечето произволни заявки работят доста ефективно (за разлика от RDBMS, където често трябва да оптимизирате и денормализирате след факта).
Заключение: Въпреки че МОЖЕТЕ да използвате SOLR като RDBMS, може да откриете (както и аз), че в крайна сметка няма "безплатен обяд" - и спестяването на разходи от супер готино търсене на текст в lucene и високопроизводително индексиране в паметта, често се заплащат от по-малко гъвкавост и приемане на нови работни потоци за достъп до данни.
