Elasticsearch solo срещу Couchbase+Elasticsearch

Нека опиша проблема. Сега съм на етап архитектурни промени. Преди използвах Elasticsearch като инструмент за агрегиране и търсене, но сега обмислям да го използвам като основна база данни. Четох, че не се препоръчва използването на Elasticsearch като основна база данни, а само като индекс. Така че прочетох презентация за връзката му с Couchbase:

https://2013.nosql-matters.org/bcn/wp-content/uploads/2013/12/nosql13-bcn-couchbase-elasticsearch-jeroen-reijn.pdf

Изтеглих и инсталирах Couchbase и плъгин за интеграция с Elasticsearch

https://github.com/couchbaselabs/elasticsearch-transport-couchbase

Не съм убеден в това решение. Първо, агрегирането е по-бързо в Elasticsearch. Второ, Elasticsearch поддържа хистограма, геоточки, пълнотекстово търсене и много други, така че изглежда, че единствената причина да запазите Couchbase е да нямате Elasticsearch като основна база данни.

Така че въпросът ми е за предимствата на интегрирането на Elasticsearch с Couchbase в моя случай?


bigdata couchbase
person esnosek    schedule 27.11.2015    source източник

Отговори (3)


arrow_upward
0
arrow_downward

Използвам ES като база данни от няколко години, никога не съм имал проблем, докато пробвах и MongoDB с много проблеми!

Винаги е добре да имате резервно копие на данните, във вашия случай с "Couchbase", но не е необходимо. Можете да създавате моментна снимка на ES всеки ден, това може да е достатъчно.

Важно е да се има предвид, че ES е „почти реално време“, което означава, че данните са налични няколко пъти (милисекунди) след изданието.

ES е бърз, лесен за настройка и много добре мащабиран. HTTP протоколът е най-добрият начин за комуникация на всякакви езици.

person Thomas Decaux    schedule 02.12.2015
comment
Мисля, че е важно да се изясни, че ES е търсачка (и не DB, както мнозина мислят). Според моето разбиране за тези, при които загубата на данни не е възможна (сигурност, финансови и т.н.), не използвайте ES като основно хранилище на данни discuss.elastic.co/t/elasticsearch-as-a-primary-database/85733/ - person Yohan; 16.03.2019

arrow_upward
0
arrow_downward

Използването на приставката couchbase ще позволи промените в данните в Couchbase автоматично да бъдат (пре)индексирани в Elasticsearch. Все пак може да искате да разгледате дали схемата/картографирането, което Couchbase може да наложи, е подходящо за вашите запитвания. След като данните са в Elasticsearch, все още можете да ги правите заявки, като използвате заявките Elasticsearch директно, за да правите неща като търсения или агрегиране.

Едно предимство от използването на Couchbase може да бъде, че позволява репликация между центрове за данни (използвайки множество клъстери elasticsearch), докато обикновено наличието на Elasticsearch в множество центрове за данни не е препоръчителна практика.

person Sarwar Bhuiyan    schedule 08.12.2015

arrow_upward
0
arrow_downward

Единственият значим проблем, с който съм се сблъсквал досега с използването на elasticsearch като основно хранилище на данни, е забавянето на индексирането, когато индексирате нов документ. Elasticsearch е "почти" търсачка в реално време... квалификаторът "близо" е необходим, защото има до 1 секунда забавяне, след като индексирате документ, преди той да бъде намерен по време на търсене.

Ето връзка към съответната част от ръководството за elasticsearch:

Търсене в почти реално време в elasticsearch

Това беше проблем в създадено от мен уеб приложение, което съдържа страница със списък на потребителите. Моят сценарий беше, че администраторът щракна върху бутона „нов потребител“ на страница със списък на потребители и след това беше прехвърлен на друга страница, за да създаде потребителя. Когато администраторът запази потребителския документ, той беше пренасочен към страницата със списък, но новосъздаденият потребител не се появи поради забавянето на индексирането на elasticsearch.

Ръководството за elasticsearch казва, че можете ръчно да опресните индекса, но казва да не го правите в производството.

...не правете ръчно опресняване всеки път, когато индексирате документ в производство; това ще навреди на представянето ви. Вместо това вашето приложение трябва да е наясно с естеството на Elasticsearch в почти реално време и да го съобразява.

Така или иначе опресних индекса, тъй като създаването на нови потребители е много рядко явление в приложението ми, но не е много добро решение.

Публикувах въпрос преди няколко месеца, питайки как други хора заобикалят този проблем:

Как да се справите със забавянето на индекса на Elasticsearch

Отговорът на този въпрос имаше предложение, което ми хареса. По принцип авторът предлага да вмъкнете записа в списъка ръчно, като използвате данните, които изпращате, вместо да чакате връщане от сървъра. Това трябва да работи, стига да не разчитате на полета, генерирани от сървъра.

В крайна сметка обаче не трябва да се сблъсквате с този проблем с база данни като Couchbase.

person Troy    schedule 15.02.2016