Size: a a a

2017 January 23

ℝuƷ1Ʒʒ7 in Elasticsearch
Anatoly
в смысле не уверен? Вот одна машина, памяти 128 Гб. У вас данных 256 Гб и все нужны. Я вас уверяю, шардирование сильно поможет
ОЗУ? Эластик же не in-memory, зачем, когда на SSD мы ничего не теряем, не возможно обрабатывать ещё быстрее данные, чем IO
источник

ℝuƷ1Ʒʒ7 in Elasticsearch
Про шарды, как я понял из вашего обсуждения, что всё зависит от кол-во данных для хранения. Как же тогда создаются индексы и хэши/деревья, они хранятся по шардам или в едином месте?
источник

ℝuƷ1Ʒʒ7 in Elasticsearch
*не IO, а как раз обработка данных (процессорным временем) к скорости IO
источник

E

Etki in Elasticsearch
Общие рекомендации - от планируемого количества узлов и из расчета не больше 32 гб / шард
источник

E

Etki in Elasticsearch
В памяти много чего хранится для ускорения
источник

E

Etki in Elasticsearch
Про 32 гб на шард хз на самом деле, потому что шард не будет располагаться в памяти в размере 1:1
источник

ℝuƷ1Ʒʒ7 in Elasticsearch
Я почему заинтересовался, т.к. у меня нет больших объёмов, у меня всех данных гигов 20. Но при этом эластик у меня основное хранилище.
Так вот, я сейчас как раз задался вопросом пересоздания индексов и изучаю как вообще данные распределяются по репликам и шардам, чтобы понять как правильно их хранить.
Сейчас у меня есть некая версионность данных, каждый индекс имеет префикс версии через алиасы типа users_v3 -> users, так же данные распределены по типам users_v3/abonents, users_v3/engineers, users_v3/operators и т.п.
И вот у меня возник вопрос, как они разносятся по шардам, каждый тип в разном шарде или всё в перемешку с указателями
источник

NK

ID:57684913 in Elasticsearch
А меня переход на эластик останавливает проблема перестройки индексов в основном. Щас ведь на лайве маппинг не поменять?
источник

E

Etki in Elasticsearch
Не поменять
источник

NK

ID:57684913 in Elasticsearch
Бизнес требования раз в месяц меняет, я с эластиком как основной базой сдохну )
источник

E

Etki in Elasticsearch
От использования в качестве хранилища лучше отказаться
источник

E

Etki in Elasticsearch
Там с самого начала нужно реиндексы настраивать для апдейта мапптнга
источник

E

Etki in Elasticsearch
Чтобы при каждом деплое при смене версии ротировался индекс :/
источник

A

Anatoly in Elasticsearch
Etki
Только больше 32 гб не стоит выписывать из-за oop
только оставшуюся память люсен сожрёт под свои нужды и под memory-mapped files
источник

E

Etki in Elasticsearch
Это дикий геморрой, но в пятерке сделали спец ручку для этого
источник

E

Etki in Elasticsearch
https://www.elastic.co/guide/en/elasticsearch/reference/master/docs-reindex.html вот вроде (я как всегда с телефона)
источник

A

Anatoly in Elasticsearch
ℝuƷ1Ʒʒ7
Я почему заинтересовался, т.к. у меня нет больших объёмов, у меня всех данных гигов 20. Но при этом эластик у меня основное хранилище.
Так вот, я сейчас как раз задался вопросом пересоздания индексов и изучаю как вообще данные распределяются по репликам и шардам, чтобы понять как правильно их хранить.
Сейчас у меня есть некая версионность данных, каждый индекс имеет префикс версии через алиасы типа users_v3 -> users, так же данные распределены по типам users_v3/abonents, users_v3/engineers, users_v3/operators и т.п.
И вот у меня возник вопрос, как они разносятся по шардам, каждый тип в разном шарде или всё в перемешку с указателями
у каждого индекса свои шарды, не связанные с шардами других индексов
источник

ℝuƷ1Ʒʒ7 in Elasticsearch
Anatoly
у каждого индекса свои шарды, не связанные с шардами других индексов
а распределение типов в индексе по шардам?
источник

ℝuƷ1Ʒʒ7 in Elasticsearch
ID:57684913
Бизнес требования раз в месяц меняет, я с эластиком как основной базой сдохну )
именно поэтому у меня версионность, поддержка сделана один раз на уровне приложения
источник

A

Anatoly in Elasticsearch
ℝuƷ1Ʒʒ7
а распределение типов в индексе по шардам?
нигде не описано. в каждом шарде могут быть свои типы. AFAIK, тип - это просто строковое поле в объекте
источник