# Как правильно распределить данные в индекс(е/ах) **URL:** \ **Category:** Вопросы на русском языке\ **Created:** [January 27, 2018, 2:48pm UTC](https://discuss.elastic.co/t/topic/117310 "2018-01-27T14:48:48Z")\ **Posts on this page:** 16\ **Page:** 1
**Author:** ![akaNightmare](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/akanightmare/32/27027_2.png) [@akaNightmare](https://discuss.elastic.co/u/akaNightmare)\ **Post date:** [January 27, 2018, 2:48pm UTC](https://discuss.elastic.co/t/topic/117310/1 "2018-01-27T14:48:48Z")
Здравствуйте, хочу задать практический вопрос, а именно как правильно хранить/распределить данные (в моем случае транзакции по платежам, ордера, возвраты, отмены) по продуктам. Суть в том, что из этих всех транзакций строятся различного типа репорты типа: сколько покупок было сделано или суму всех ордеров или возвратов за последний день/неделю/месяц/год/другая кастомная дата. Есть идея создавать индекс на каждый день и/или по типу транзакции типа `type: 'ORDER'`/`type: 'REFUND'` и тд. и "навешать" на них alias типа ``` POST last_moth_sales/_search { "query": { "bool": { "must": [ { "match": { "type": "ORDER" } }, { "range": { "timestamp": { "gte": "now-1M", "time_zone": "-03:00" } } } ] } } } ``` Даст ли такая разбивка скорость при выборке и тем более при агрегации данных и есть ли какие-то best practices для подобных случаев? Буду благодарен за любую подсказку. PS: данных может быть очень много(примерно 10КК каждый день), каждый документ может "весить" от 5 до 10КB ---
**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:** [January 29, 2018, 4:43pm UTC](https://discuss.elastic.co/t/topic/117310/2 "2018-01-29T16:43:10Z")
> [@akaNightmare](#): > > PS: данных может быть очень много(примерно 10КК каждый день), каждый документ может "весить" от 5 до 10КB Это на самом деле не так много. Вы видите замедление в работе? При каком объеме данных? Как долго вы собираетесь хранить данные о транзакциях? ---
**Author:** ![akaNightmare](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/akanightmare/32/27027_2.png) [@akaNightmare](https://discuss.elastic.co/u/akaNightmare)\ **Post date:** [January 29, 2018, 5:56pm UTC](https://discuss.elastic.co/t/topic/117310/3 "2018-01-29T17:56:59Z")
данные должны хранится всегда, так как предусмотрен фильтр за последний год или выбрать любую дату от и до. Хотелось бы знать как лучше их хранить в каком формате, нужно ли их разбивать на индексы или что-то в этом роде. ---
**Author:** ![akaNightmare](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/akanightmare/32/27027_2.png) [@akaNightmare](https://discuss.elastic.co/u/akaNightmare)\ **Post date:** [January 29, 2018, 5:59pm UTC](https://discuss.elastic.co/t/topic/117310/4 "2018-01-29T17:59:06Z")
причина выбора ES, из-за того что MongoDB никак не справляется с агрегацией, запустив один и тот же запрос для MongoDB и для ES результаты были ошеломляющие самый долгий/кривой запрос на MongoDB выполняется 300-400sec и на ES ~500ms и это без тюнинга и всего остального. ---
**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:** [January 29, 2018, 7:20pm UTC](https://discuss.elastic.co/t/topic/117310/5 "2018-01-29T19:20:01Z")
Обычно, на индексы разбивают для того, чтобы проще было удалять старые данные и для того, чтобы оптимизировать поиск по новым данным. Если вас скорость поиска устраивает и старые данные удалять не надо, то единственная причина на использование нескольких индексов - это изменение схемы со временем. Но с этим надо обращаться осторожно, так как ваш поиск должен будет работать и со старым форматом - и с новым. Так что даже в этом случае, если данных не так много - проще просто все переиндексировать. Я думаю, что новый индекс каждый месяц или год - должен для вас вполне работать. Сильнее я бы не разбивал. ---
**Author:** ![akaNightmare](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/akanightmare/32/27027_2.png) [@akaNightmare](https://discuss.elastic.co/u/akaNightmare)\ **Post date:** [January 29, 2018, 7:24pm UTC](https://discuss.elastic.co/t/topic/117310/6 "2018-01-29T19:24:40Z")
а как делать запрос через индексы, типа у меня есть 3 индекса - trans\_201801 - trans\_201802 - trans\_201803 и есть запрос что-то типа ``` { "query": { "bool": { "must": [ { "range": { "timestamp": { { "to": "2018/01/01" }, { "from": "2018/03/03" }, } } ] } } } ``` как в этом случае будет искаться по 3 индексам как мне знать что нужно искать именно в этих трех индексах и тд? ---
**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:** [January 29, 2018, 7:57pm UTC](https://discuss.elastic.co/t/topic/117310/7 "2018-01-29T19:57:10Z")
> [@akaNightmare](#): > > как в этом случае будет искаться по 3 индексам как мне знать что нужно искать именно в этих трех индексах и тд? Вам [не нужно](https://www.elastic.co/blog/instant-aggregations-rewriting-queries-for-fun-and-profit) это знать. Ищите всегда по всем индексам. ---
**Author:** ![akaNightmare](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/akanightmare/32/27027_2.png) [@akaNightmare](https://discuss.elastic.co/u/akaNightmare)\ **Post date:** [January 29, 2018, 8:14pm UTC](https://discuss.elastic.co/t/topic/117310/8 "2018-01-29T20:14:55Z")
а есть ли смысл разбивать еще и по пользователям типа - trans\_user1\_1801 - trans\_user2\_1801 - trans\_user1\_1802 - trans\_user2\_1802 и если да то сразу следущий вопрос на типи транзакций - trans\_user1\_SALES\_1801 - trans\_user2\_SALES\_1801 - trans\_user1\_ORDERS\_1802 - trans\_user2\_ORDERS\_1802 ---
**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:** [January 29, 2018, 8:22pm UTC](https://discuss.elastic.co/t/topic/117310/9 "2018-01-29T20:22:47Z")
"Преждевременная оптимизация — корень всех (или большинства) проблем в программировании." 🙂 ---
**Author:** ![akaNightmare](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/akanightmare/32/27027_2.png) [@akaNightmare](https://discuss.elastic.co/u/akaNightmare)\ **Post date:** [January 29, 2018, 8:35pm UTC](https://discuss.elastic.co/t/topic/117310/10 "2018-01-29T20:35:44Z")
вопрос в том будет ли быстрее выборка если кол-во выборка будет по нескольким индексам и где можно почитать именно как оно работает "под капотом"? ---
**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:** [January 29, 2018, 10:25pm UTC](https://discuss.elastic.co/t/topic/117310/11 "2018-01-29T22:25:38Z")
> [@akaNightmare](#): > > вопрос в том будет ли быстрее выборка если кол-во выборка будет по нескольким индексам Это сложный и многогранный вопрос - с одной стороны распределение по многим индексам позволит исполнять поиск на многих потоках одновременно, один поток на каждую шарду. С другой стороны - чем больше шард - тем больше времени будет нужно, что бы слить результаты поиска. То есть - одна шарда - слишком мало, 1000 шард - слишком много, (но опять же 1000 шард может быть и ничего, если у вас порядка 100 нод, например). К тому же, увеличить количество шард можно и для одного индекса. Короче, надо смотреть на конкретные индексы, данные, машины, диски и тестировать. Теоретически на этот вопрос не ответить. Мой подход - начать с одного индекса с установками по умолчанию и грузить туда данные, пока не начнет тормозить, после этого - смотреть где тормоза, и решать проблему соответственным образом. > [@akaNightmare](#): > > и где можно почитать именно как оно работает "под капотом"? Можно начать [тут](https://www.elastic.co/guide/en/elasticsearch/guide/current/distributed-search.html). ---
**Author:** ![akaNightmare](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/akanightmare/32/27027_2.png) [@akaNightmare](https://discuss.elastic.co/u/akaNightmare)\ **Post date:** [February 20, 2018, 2:02pm UTC](https://discuss.elastic.co/t/topic/117310/12 "2018-02-20T14:02:25Z")
Понял, благодарю. Есть ли какие-то "подводные камни" если документ может содержать разное колл-во полей типа как у MongoDB? ---
**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 20, 2018, 2:57pm UTC](https://discuss.elastic.co/t/topic/117310/13 "2018-02-20T14:57:22Z")
Посмотрите [тут](https://www.elastic.co/guide/en/elasticsearch/reference/current/general-recommendations.html#sparsity). ---
**Author:** ![akaNightmare](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/akanightmare/32/27027_2.png) [@akaNightmare](https://discuss.elastic.co/u/akaNightmare)\ **Post date:** [March 6, 2018, 2:46pm UTC](https://discuss.elastic.co/t/topic/117310/14 "2018-03-06T14:46:58Z")
не могу закрыть вопрос ---
**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:** [March 6, 2018, 5:00pm UTC](https://discuss.elastic.co/t/topic/117310/15 "2018-03-06T17:00:42Z")
Вопросы закрываются автоматически после месяца тишины. Вы можете пометить ответ, как решение, нажав на `...` под ответом и потом выбрав ✅ ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [April 3, 2018, 5:00pm UTC](https://discuss.elastic.co/t/topic/117310/16 "2018-04-03T17:00:50Z")
Closed on April 3, 2018, 5:00pm UTC This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.