Хранение данных в ElasticSearch?

Question

[dark_spectator]

Использую ElasticSearch как основное хранилище данных. Вопрос с том как хранить в нем дополнительную информацию о пользователе.
В данный момент есть 2 индексов

socket-apps-db : {
   users: {
      "user_id" : {
         "login" : "user_login",
         "email": "user_email",
         "password" : "user_password",
      }
   }
}

socket-apps-{game_name}-cloud : { // {game_name} - Название игры, для которой облако

  "data" : {
  "user_id" : {
    "level" : 5,
    "cloud": "{cloud_data}"
}
}

}

еще планирую так-же хранить друзей пользователя и сообщения, для каждого диалога отдельный индекс, для списка друзей пользователя тоже. ID хранятся в Redis.

Вопрос в том правильно ли я всё делаю?
Желательно в 1 индексе создавать несколько типов для этих вещей, но ElasticSearch говорит что только 1 тип на индекс.
Или как вообще реализовывать подобную структуру и какие базы/инструменты использовать?

Comments

[Алексей]

ElasticSearch не очень хорошо переносит операции DELETE, UPDATE. Посмотрите на Монго, если не хочется SQL. В 4-ой версии есть поддержка ACID, из плюшек горизонтальное масштабирование без боли, за счет автошардирования, если будете интенсивно расти

Answer 1

[Иван Шумов]

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

Comments

[dark_spectator]

Хорошо, что в таком случае использовать? Не загнётся ли MySQL если в таблице будет 2-3МЛРД строк и я захочу сделать поиск по ней, по логину?

[Иван Шумов]

dark_spectator, зависит от архитектуры - какие запросы, какие индексы, какая нагрузка, какой сервер.... Если что то эластик жрет как не в себя в отличии от MySQL/Postges

[chupasaurus]

Поправка: Elasticsearch нужен исключительно для полнотекстового поиска.

[Иван Шумов]

chupasaurus, твоя правда)

[dark_spectator]

Иван Шумов, А если представить, то как в MySQL хранить друзей пользователя, его сообщения? Под каждого бзера генеритт новую таблицу? типа userid_friends,
userid_userid_messages?

[Иван Шумов]

dark_spectator, вам стоит узнать еще много про базы данных и горизонтальное масштабирование. Явно не предмет данного вопроса

[Алексей]

chupasaurus, нет не поправка, это еще и OLAP

[Алексей]

Иван Шумов, вот с чего бы он жрет как не в себя? Если руки прямые, все норм. А с учетом шардирования и отказоустойчивости так вообще конфета в отличии от PostgreSQL/MySQL. Ах да ну и гео-репликация, да за деньги но она хотя бы есть из коробки

[Иван Шумов]

Алексей, это такой себе OLAP. Есть куда лучше инструменты

[Иван Шумов]

Алексей, да все с этим хорошо, я не спорю. Идёт же сравнение для OLTP задач) там уже сравнение идёт не в пользу эластика

[Алексей]

Иван Шумов, clickhouse, vertica?

[Иван Шумов]

Алексей, в моем случае абсолютно другие инструменты. Я сейчас на вендор-лок AWS поэтому redshift, emr, Athena.

[Алексей]

Иван Шумов, это уже решения от Amazon, я имел ввиду собственный инстанс. Тут соглашусь, если живешь в инфраструктуре Amazon, то жизнь проще. Хотя опять тот же ElasticSearch as service отвратительно работает у Amazon. Лично людям перенастраивал на EC2, поднимал собственный кластер ElasticSearch, как итог время отклика снизилось с 220 ms снизился до 25-27 ms. И цена уменьшилась. Хотя я могу понять Amazon, нужно продавать как можно больше, поэтому об оптимизации и речи быть не может. За не знания и отсутствие желания надо платить)

[Иван Шумов]

Алексей, на самом деле тут пошел холивар, но все-же ES в AWS пропагандируется как HA Resilent Self-Management service, поэтому он дороже, разумеется. Из коробки. Отклик медленный может быть только из-за 2 причин - неправильно подобранные ресурсы и неправильные настройки сети (привет криворуким новичкам в облаках)

А теперь. О стоимости. Всегда есть возможность сильно понизить стоимость compute ресурсов c помощью Reserved instances и spot instances. Когда начинаешь работать с ресурсами постоянно и планируешь траты на перед то получается очень дёшево. Я экономил до 70-80% относительно on demand

[Алексей]

Иван Шумов, давайте заканчивать холивар) Но есть маленькое но, ElasticSearch написан на Java и многое зависит от ее версии и тюнинга (например GC) к чему доступ не имеешь при SaaS. И как оно настроено тоже не известно. Да и сам Elastic имеет свои механизмы отказоустойчивости

[Иван Шумов]

Алексей, согласен) остальную часть своего мнения и знания оставлю при себе