Как правильно проиндексировать большой объем информации в elasticsearch?

Question

[nicolaa]

Создал команду в Laravel, в ней получаю все товары
$prod = Prod::cursor();
Перебираю и записываю в elasticsearch

$this->elasticsearch->index([
  'index' => 'prods',
  'type' => 'prod',
  'id' => $prod->prods_id,
  'body' => [
    'site_id' => $prod->site_id,
    'category_id' => $prod->category_id,
    'fields' => $prod->field,
    'priority' => $prod->priority,
    'prod_updated_at' => $prod->updated_at_p,
    'prod_created_at' => $prod->created_at_p,
    'site_rating' => $prod->site_rating,
    'prod_rating' => $prod->prod_rating,
  ],
]);

Записей в БД более 2 миллионов
В среднем в elasticsearch записывается 23 000 товаров в час, это получается, что для записи все БД потребуется где-то 4 дня

Возможно ли записать более быстрым способом?

Answer 1

[d'Ivan]

Хотя с ES мало работал и мне показалось странным, что индекс нужно строить по такому количеству полей. Какой в этом практический смысл? Почему не хранить в ES лишь то, что требуется искать и/или анализировать? Ведь для остальных случаев можно использовать реляционную СУБД.
Маш. перевод про индексы и мощность

Comments

[nicolaa]

Спасибо за статью
В elasticsearch записываются только поля по которым будет идти поиск и сортировка списка, или я не правильно делаю?
По моей логике, я делаю поиск в elasticsearch, нахожу id, сортирую id в нужном мне порядке, делаю пагинацию и затем отдаю эти id в БД (MySQL) и с БД вывожу товары на сайт

[chupasaurus]

nicolaa, похоже на правильное использование, вопрос только в том, где и как и вы сортируете результаты поиска.

Answer 2

[Flying]

Используйте Bulk API, через него загрузка в десятки раз быстрее чем по одному документу заливать.

Правда закидывать всё одним bulk'ом тоже не стоит, практика показывает что пакеты порядка сотни документов за раз - вполне, хотя от размеров одного документа тоже зависит.

Answer 3

[Vitaly Karasik]

Записей в БД более 2 миллионов
В среднем в elasticsearch записывается 23 000 товаров в час, это получается, что для записи все БД потребуется где-то 4 дня

У меня два вопроса, один из которых слегка офф-топик
1) на каком сервере это бежит и что показывает top?
2)  а чем вас не устраивает 4 дня на первичное заполнение базы? Дальше-то будете добавлять только новые записи?

Comments

[nicolaa]

Процессор Intel Core i7 3.40 GHz
12 гб оперативной памяти
1 тб HDD
Что значит показывает top?

Это первичное единоразовое заполнение, дальше только добавление новых товаров, изменение/удаление имеющихся

Просто с elasticsearch работаю впервые и как-то цифра в 4 дня показалась большой

[Vitaly Karasik]

nicolaa,
1)

1 тб HDD

если заменить HDD на SSD, должно стать быстрее.

Что значит показывает top?

Я имею в виду вывод утилиты top или графики системы мониторинга.
2)

Просто с elasticsearch работаю впервые и как-то цифра в 4 дня показалась большой

Наверняка можно оптимизировать Elastic. Но если темпы обновления базы не слишком большие, то Elastic с ними вполне справится, и я бы не заморачивался из-за одноразовой операции.

[nicolaa]

Vitaly Karasik, В среднем процесс записи занимаем 1% ЦП и 600 мб оперативной памяти
Понял, спасибо, буду ждать завершения записи

[Василий Банников]

nicolaa, вполне возможно, тут всё упирается в скорость диска. Я бы рассматривал переход на SSD в будущем

[Vitaly Karasik]

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

https://www.elastic.co/guide/en/elasticsearch/refe...

например

-Xmx4g -Xms4g

[nicolaa]

Vitaly Karasik, Спасибо, буду разбираться

[chupasaurus]

Vitaly Karasik, в отсутствии чтения и при записи всего в один индекс оперативная память будет использоваться под незаписанные объекты и холодные метаданные, так что скорости не прибавит.