Сейчас вышел Elasticsearch 2.0, и я начинаю думать над вопросами миграции. Натолкнулся на два концептуальных вопроса, которые хотелось бы понять. мне кажется, в рускоязычном сообществе Вы единственный можете объяснить логику создателей.
Утилита проверки готовности миграции говорит, что теерь тип boolean надо интерпретировать как 0 и 1 вместо false и true. В документации тип boolean остался, по прежнему в него можно записывать true и false, но при выборках нужно использовать 0 и 1. С чем это связано? Какие задачи быи решены таким решением?
Утилита миграции говорит, что недопустимо в одном индексе иметь два типа с двумя полями с разным меппингом. То есть если у меня есть поле в типе users name, и поле name в типе streets, и они имеют разный mapping, то это фатальная ошибка. Я полагал, что index - это аналог database, а type - аналог таблицы, но видимо ошибался. Какой смысл имеет понятие index и type в Elastic 2.0?
Это вызвано тем, что изменился формат хранения этих данных. На сколько я помню, это изменение было произведено для улучшения производительности полей с данным типом.
Type - это не совсем аналог таблицы. Это скорее подмножество полей из множества всех полей в индексе. То есть, в вашем примере поле name от всех типов индексируется как одно и тоже поле name на уровне lucene. В 1.x, это не было очевидно и вызывало "странные" проблемы для пользователей, пытавшихся использовать тип как таблицу. В 2.0 мы сделали так, что задать поля с одним именем но разными опциями больше в разных типах просто не возможно.
А разница в производительности действительно настолько заметна? И почему бы не пойти по пути, что внутренее представление, скажем, числом, а на уровне запроса происходит просто "прозрачная" конвертация?
По второму вопросу немного странно. Получается, что в ES 2.0 фактически, надо кждую "таблицу" создавать "индексом". А какие тогда есть механизмы обособления "таблиц" в рамках одного проекта? У меня на сервере сейчас крутится около 5 проектов, и для каждого из них сделан отдельный индекс. При переходе к новой версии, мне нужен иной механизм разделения данных. Как правильно? На уровне префиксов индексов? Или ставить разные инстансы ES на каждый проект? Но IMHO, это не совсем оправдано по ресурсам.
В большинстве случаев прозрачная конвертация и происходит. Просто есть пара случаев, где это не было практично. См ссылку в моем предыдущем ответе с примерами таких случаев.
Эта проблема с возможными решениями очень хорошо описана в статье Great Mapping Refactoring. Если будет что не понятно - спрашивайте тут.
Да, теперь внимательне прочел - стало понятней. Но детали остались.
Правильно ли я понимаю, что когда я создам в mapping тип boolean, то он создастся как "целое". И если я при записи буду указывать 0/1 - то оно и будет как целое хранится. Но если я сделаю присвоение этому типу true - то сохранится строковое выражение "Т", или же ES 2.0 сам конвертирует это значение в 1 "целое"?
По второму вопросу проблематика понятна. Видимо - самый оптимальный вариант - рассматривать индексы как отдельные таблицы. Вариант с разным названием однотипных полей мне представляется эстетически нежелательным.
Можно что угодно в это поле записывать. При этом false, "false", "off", "no", "0", "", 0, 0.0 будет интерпретироваться как false и храниться как 0, а все остальное будет интерпретироваться как true и храниться как 1.
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant
logo are trademarks of the
Apache Software Foundation
in the United States and/or other countries.
