# Как правильно сортировать выдачу? **URL:** \ **Category:** Вопросы на русском языке\ **Created:** [November 27, 2015, 9:35am UTC](https://discuss.elastic.co/t/topic/35729 "2015-11-27T09:35:25Z")\ **Posts on this page:** 3\ **Page:** 2
**Author:** ![stanleer](https://avatars.discourse-cdn.com/v4/letter/s/d07c76/32.png) [@stanleer](https://discuss.elastic.co/u/stanleer)\ **Post date:** [February 11, 2016, 8:47am UTC](https://discuss.elastic.co/t/topic/35729/21 "2016-02-11T08:47:16Z")
Что плохого в пользовании как реляционной базой?) Я не раз встречаю такое использование и сам сейчас пробую сделать листинг объектов на эластике. Вывод постранично и по параметрам тоже можно считать поиском ) На монге похожая схема хранения документов и пользуются же. ---
**Author:** ![Igor\_Motov](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/igor_motov/32/45193_2.png) [@Igor\_Motov](https://discuss.elastic.co/u/Igor_Motov)\ **Post date:** [February 11, 2016, 4:38pm UTC](https://discuss.elastic.co/t/topic/35729/22 "2016-02-11T16:38:11Z")
> [@stanleer](#): > > Что плохого в пользовании как реляционной базой? Я согласен с тем, что внешне Elasticsearch и реляционные базы в чем-то похожи. Обе системы позволяют хранить данные и получать данные обратно с помощью языка запросов. Многие пользователи Elasticsearch переходят на него с SQL, и поэтому идея использования SQL для поиска Elasticsearch не нова. Если у вас хорошо с английским, я бы мог посоветовать посмотреть вот [эту презентацию](https://www.elastic.co/videos/elasticsearch-for-sql-users), в которой рассказывается, как "перевести" многие запросы из SQL в elasticsearch и я знаю как минимум 3 проекта, которые пытаются сделать это автоматически. Однако, с моей точки зрения, использование SQL для поиска по Elasticsearch будет скорее вредить пользователям, чем им помогать. Из моего опыта, использование elasticsearch как реляционной базой не приводит ни к чему хорошему, потому что эти системы похожи только на поверхности. При серьезной нагрузке и масштабе, внутренние различия становятся все более и более важны, и в долгосрочной перспективе, вам будет гораздо легче, если вы начнете с самого начала подходить к Elasticsearch как поисковому и аналитическому движку, а не как к базе данных. Чтобы не быть голословным, приведу несколько примеров. При моделировании данных в реляционной базе, стандартной практикой является нормализация данных, что во многих случаях является абсолютно неприемлемым решеним для Elasticsearch из-за отсутствия в нем механизмов объединения запросов по нескольким таблицам. При этом, вместо того, чтобы пользоваться мощным механизмом анализа и поиска текста, прямая миграция с реляционной базы обычно приводит к индексированию всех поле без анализа и поиском по `*foobar*`, что опять же является одним из самых неоптимальных запросов в Elasticsearch. Хотя агрегации и напоминают группировку, это совсем другой процесс, и то, что возможно добиться группировкой, не всегда можно реализовать через агрегацию и наоборот. Поисковые движки оптимизированы для поиска по большому количеству полей одновременно, и индексирование данных никогда не блокирует чтение и поиск, но при этом требования ACID в поисковых движках либо не поддерживаются совсем, либо работают только на уровне одной записи, и т.д. ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [July 6, 2017, 1:49pm UTC](https://discuss.elastic.co/t/topic/35729/23 "2017-07-06T13:49:30Z")
[Previous page](https://discuss.elastic.co/t/topic/35729.md?page=1)