Как правильно распределить данные в индекс(е/ах)

Elastic In Your Native Tongue Вопросы на русском языке
1

Здравствуйте,

хочу задать практический вопрос, а именно как правильно хранить/распределить данные (в моем случае транзакции по платежам, ордера, возвраты, отмены) по продуктам. Суть в том, что из этих всех транзакций строятся различного типа репорты типа: сколько покупок было сделано или суму всех ордеров или возвратов за последний день/неделю/месяц/год/другая кастомная дата.

Есть идея создавать индекс на каждый день и/или по типу транзакции типа 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

2

Это на самом деле не так много. Вы видите замедление в работе? При каком объеме данных?
Как долго вы собираетесь хранить данные о транзакциях?

3

данные должны хранится всегда, так как предусмотрен фильтр за последний год или выбрать любую дату от и до. Хотелось бы знать как лучше их хранить в каком формате, нужно ли их разбивать на индексы или что-то в этом роде.

4

причина выбора ES, из-за того что MongoDB никак не справляется с агрегацией, запустив один и тот же запрос для MongoDB и для ES результаты были ошеломляющие самый долгий/кривой запрос на MongoDB выполняется 300-400sec и на ES ~500ms и это без тюнинга и всего остального.

5

Обычно, на индексы разбивают для того, чтобы проще было удалять старые данные и для того, чтобы оптимизировать поиск по новым данным. Если вас скорость поиска устраивает и старые данные удалять не надо, то единственная причина на использование нескольких индексов - это изменение схемы со временем. Но с этим надо обращаться осторожно, так как ваш поиск должен будет работать и со старым форматом - и с новым. Так что даже в этом случае, если данных не так много - проще просто все переиндексировать.

Я думаю, что новый индекс каждый месяц или год - должен для вас вполне работать. Сильнее я бы не разбивал.

6

а как делать запрос через индексы, типа у меня есть 3 индекса

  • trans_201801
  • trans_201802
  • trans_201803

и есть запрос что-то типа

{
   "query": {
     "bool": {
       "must": [
         {
           "range": {
             "timestamp": {
               { "to": "2018/01/01" }, 
               { "from": "2018/03/03" },
           }
         }
       ]
     }
   }
 }

как в этом случае будет искаться по 3 индексам как мне знать что нужно искать именно в этих трех индексах и тд?

7

Вам не нужно это знать. Ищите всегда по всем индексам.

8

а есть ли смысл разбивать еще и по пользователям типа

  • 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
9

"Преждевременная оптимизация — корень всех (или большинства) проблем в программировании." :slight_smile:

10

вопрос в том будет ли быстрее выборка если кол-во выборка будет по нескольким индексам и где можно почитать именно как оно работает "под капотом"?

11

Это сложный и многогранный вопрос - с одной стороны распределение по многим индексам позволит исполнять поиск на многих потоках одновременно, один поток на каждую шарду. С другой стороны - чем больше шард - тем больше времени будет нужно, что бы слить результаты поиска. То есть - одна шарда - слишком мало, 1000 шард - слишком много, (но опять же 1000 шард может быть и ничего, если у вас порядка 100 нод, например). К тому же, увеличить количество шард можно и для одного индекса. Короче, надо смотреть на конкретные индексы, данные, машины, диски и тестировать. Теоретически на этот вопрос не ответить. Мой подход - начать с одного индекса с установками по умолчанию и грузить туда данные, пока не начнет тормозить, после этого - смотреть где тормоза, и решать проблему соответственным образом.

Можно начать тут.

12

Понял, благодарю.

Есть ли какие-то "подводные камни" если документ может содержать разное колл-во полей типа как у MongoDB?

13

Посмотрите тут.

14

не могу закрыть вопрос

15

Вопросы закрываются автоматически после месяца тишины. Вы можете пометить ответ, как решение, нажав на ... под ответом и потом выбрав :white_check_mark:

16

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.