Этот пост объясняет, как можно использовать поисковый сервер ElasticSearch в качестве базы данных. Я использую ElasticSearch как свою единственную систему хранения данных, потому что для Jetslide я хочу избежать затрат времени на обслуживание и разработку, которые потребуются при использовании отдельной системы. Будь то NoSQL, объект или чистые базы данных SQL.
ElasticSearch — это действительно мощный поисковый сервер на основе Apache Lucene. Так почему же вы можете использовать ElasticSearch в качестве единой точки правды ( SPOT ) ? Давайте начнем и пройдем все — или, по крайней мере, мои — требования к системе хранения данных! Я что-то забыл? Добавьте комментарий 
!
CRUD & Поиск
Вы можете читать, читать (см. Также получение в реальном времени ), обновлять и удалять документы разных типов. И, конечно же, вы можете выполнить полнотекстовый поиск!
Мульти аренды
Несколько индексов очень легко создавать и удалять . Это может использоваться для поддержки нескольких клиентов или просто для помещения разных типов в разные индексы, как это было бы при создании нескольких таблиц для каждого типа / класса.
Sharding и репликация
Разделение и репликация — это просто вопрос чисел при создании индекса:
curl -XPUT 'http://localhost:9200/twitter/' -d '
index :
number_of_shards : 3
number_of_replicas : 2'
Вы даже можете обновить количество реплик после «на лету». Чтобы обновить количество сегментов одного индекса, необходимо выполнить переиндексацию (см. Раздел переиндексации ниже).
Распределенная и облачная
ElasticSearch может быть распределен по множеству машин. Вы можете динамически добавлять и удалять узлы (видео). Дополнительно прочтите этот пост в блоге для получения информации об использовании ElasticSearch в «облаке».
Отказоустойчивость и надежность
ElasticSearch восстановится после последнего снимка своего шлюза, если произойдет что-то «плохое», такое как повреждение индекса или даже полное сбой кластера — подумайте, машина времени для поиска . Посмотрите это видео из Berlin Buzz Words (минут 26), чтобы понять, как «надежный и асинхронный характер» сочетается в ElasticSearch.
Тем не менее, я все еще рекомендую время от времени делать резервные копии на другой системе (или, по крайней мере, на другом жестком диске), например, в случае, если вы нажали на ошибки ElasticSearch или Lucene, или, по крайней мере, чтобы сделать его действительно безопасным.
В реальном времени получить
При использовании Lucene у вас есть задержка в реальном времени. Что в основном означает, что если вы сохраняете документ в индексе, вам придется немного подождать, пока он не появится, когда вы будете искать потом. Хотя эта задержка довольно мала: она составляет всего несколько миллисекунд и увеличивается, если индекс увеличивается. Но ElasticSearch реализует функцию получения в реальном времени в своей последней версии, которая позволяет теперь получать объект, даже если он не доступен для поиска по его идентификатору!
Обновить, зафиксировать и управление версиями
Как я уже говорил, у вас есть задержка в реальном времени при создании или обновлении (или индексации) документа. Чтобы обновить документ, вы можете использовать get в реальном времени, объединить его и вернуть обратно в индекс. Другой подход, который позволяет избежать дальнейших попаданий в ElasticSearch, заключается в вызове обновления (или фиксации в Solr) индекса. Но это очень проблематично (например, медленно), когда индекс не крошечный.
Хорошей новостью является то, что вы можете снова решить эту проблему с помощью функции ElasticSearch — она называется версионированием . Это идентично оптимистической блокировке «сайта приложения» в мире баз данных . Поместите документ в индекс и, если он потерпит неудачу, например, объедините старое состояние с новым и повторите попытку. Честно говоря, для этого нужно немного подумать об использовании очереди ошибок или чего-то подобного, но теперь у меня действительно хорошая рабочая система, защищенная модульными тестами.
Если вы думаете об этом, это действительно огромное преимущество, например, Solr. Даже если первичная индексация Solrs выполняется быстрее (никто не сравнивал производительность Solr с ES по индексированию), требуется вызов commit, чтобы сделать документы доступными для поиска, и значительно замедляет весь процесс индексации по сравнению с ElasticSearch. где вам никогда не нужно называть дорогие обновления.
индексированиями этого
Это не обязательно для нормальной базы данных. Но для поискового сервера крайне важно, например, изменить анализатор или количество сегментов для индекса. Повторное индексирование звучит сложно, но может быть легко реализовано даже без отдельного хранилища данных в ElasticSearch. Для Jetslide я храню не отдельные поля. Я храню весь документ как JSON в _source . Это необходимо для извлечения документов из старого индекса и помещения их во вновь созданный (с другими настройками).
Но ждать. Как я могу получить все документы из старого индекса? Разве это не было бы плохо с точки зрения производительности или памяти для больших показателей? Нет, вы можете использовать тип поиска сканирования , который избегает, например, скоринга.
Хорошо, но как я могу заменить мой старый индекс новым? Можно ли это сделать «на лету»? Да, вы можете просто переключить псевдоним индекса:
curl -XPOST 'http://localhost:9200/_aliases' -d '{
"actions" : [
{ "remove" : { "index" : "userindex6", "alias" : "userindex" } },
{ "add" : { "index" : "userindex7", "alias" : "uindex" } }]
}'
Производительность
Ну, ElasticSearch работает быстро. Но вам придется самим определить, достаточно ли он быстр для вашего варианта использования, и сравнить его с существующей системой хранения данных.
Многофункциональный
ElasticSearch имеет множество функций, которые вы не найдете в обычной базе данных. Например, огранка или мощный перколятор, чтобы назвать только несколько.
Вывод
В этом посте я объяснил, можно ли и как использовать ElasticSearch в качестве замены базы данных. ElasticSearch очень мощный, но, например, функция управления версиями требует немного ручной работы. Таким образом, работа с ElasticSearch больше похожа на мир JDBC или SQL, чем на мир ORM . Но я уверен, что для ElasticSearch появятся некоторые инструменты ORM, хотя я предпочитаю избегать системной сложности и всегда буду использовать «сырой» ElasticSearch.
От http://karussell.wordpress.com/2011/07/13/jetslide-uses-elasticsearch-as-database/