Резюме
Я написал один раньшеПервое знакомство с ElasticSearch Tucao, Неосознанно прошло два года. Эй, время заставляет тебя стареть. Недавно опять пользовался ЭП.Искал сводной документ прошлого, но документ был только один.Поработав над ЭП пол года, столкнулся с очень многими проблемами, а на выходе было так мало. действительно необоснованно. Пришлось снова брать ES, и обнаружил, что в ES еще много слотов, слишком много несовместимых обновлений, да и различия между версиями не маленькие.Чувствую, что ES проектировали люди с частичными теоретическими алгоритмами, а не писали инженеры . . . Как и в компании, инженеры-алгоритмы жалуются на слабые возможности алгоритмов разработки внутренних приложений, а разработчики внутренних приложений жалуются на слабые инженерные способности инженеров-алгоритмов. Как разработка приложений, ES почти похожа на это чувство. Но если нужно искать, без него не обойтись. Так как вы не можете отказаться, вы можете только наслаждаться этим.
написать анализ
Зачем вам анализировать и писать, из любопытства. Например, меня всегда озадачивали следующие вопросы.
- Почему es теряет данные
- Какой узел может быть координатным узлом
- Каковы операции индекса обновления и индекса сброса
- Где находится буфер памяти, кеш файловой системы.
- Как узлы в кластере взаимодействуют с записью
- Как хранятся данные
- Почему его можно проиндексировать, записав в кеш файловой системы?
Написать обзор
Прежде всего, мы анализируем и пишем с точки зрения распределенного кластера и используем параметры системы по умолчанию для объяснения
Кластер состоит из трех узлов, каждый из которых хранит данные, а indexA имеет 5 сегментов и 2 набора реплик. Данные распределяются следующим образом Узел 1: осколок 1 Node2: shard2, shard3, shard1-R1 (набор реплик shard1) Node3: shard4, shard5, shard-R2 (набор реплик shard1)
Чтобы упростить проблему, набор реплик shard2, shard5 и других осколков игнорирует проблему. Теперь возьмем запись в shard1 в качестве примера, чтобы проиллюстрировать проблему.
- Сначала клиент подключается к узлу координат путем опроса в соответствии с настроенным узлом подключения.
Узел координат не является одномерным описанием узла master/client/data, он относится к узлу, который обрабатывает запросы клиентов. Это описание представляет собой концепцию с координатным узлом Кассандры. Все узлы в кластере могут быть узлами координат.
- Узел coodinate вычисляет данные на shard1 с помощью хеш-алгоритма.
shard = hash(document_id) % (num_of_primary_shards), а затем отправить запрос на node1 в соответствии с информацией о сегменте, хранящейся на узле. - node1 проверяет данные индекса и записывает их в сегмент. Подробности смотрите в следующем разделе
写入到shard. - После того, как данные главного узла успешно записаны, данные отправляются на узлы набора реплик Node2 и Node3 параллельно.
- После успешной записи данных Node2 и Node3 отправляют сигнал подтверждения Node1, главному узлу shard1.
- Node1 отправляет подтверждение на координатный узел
- Координатный узел отправляет подтверждение клиенту.
Координатный узел всего процесса похож на cassandra, основной узел сегмента и набор реплик зависят от режима ведущий-подчиненный, и мастер должен решить, была ли запись успешной или нет, аналогично mysql.
написать в осколок
На третьем шаге необходимо подробно проанализировать запись в осколке.
- Данные записываются в буфер памяти
- Одновременно записывайте данные в транслог-буфер.
- Каждую 1 с данные обновляются из буфера в FileSystemCache и генерируется файл сегмента.После создания файла сегмента его можно запросить через индекс.
- После обновления буфер памяти очищается.
- Каждые 5 секунд транслог сбрасывается из буфера на диск.
- Периодически/количественно из FileSystemCache в сочетании с транслоговым содержимым
flush indexна диск. Сделайте инкрементную промывку.
Процесс записи одного узла в различных базах данных аналогичен, как правило, запись в память, запись журналов операций (для предотвращения простоя узла и потери данных в памяти), а затем сброс на диск, и есть поток, который непрерывно объединяет блоки данных. Но формат записываемых данных другой.
Кроме того, распределенная структура или структура развертывания master-slave требует, чтобы данные записывались复制Для разных узлов процесс сложнее, и каждая обработка базы данных также имеет разную логику.
elastic searchВ промежуточном процессе записи есть дополнительный слой буфера.Мы знаем, что хотя буфер и кеш предназначены для повышения эффективности записи, их принципы работы различны.
1. Буфер используется, когда скорость обработки на обоих концах системы сбалансирована (в долгосрочном масштабе). Он был введен, чтобы уменьшить влияние пакетного ввода-вывода в краткосрочной перспективе и сыграть роль в формировании трафика. Например, в задаче производитель-потребитель они генерируют и потребляют ресурсы примерно с одинаковой скоростью.Добавление буфера может компенсировать внезапное изменение, когда ресурсы только генерируются/потребляются. 2. Кэш (cache) — компромиссная стратегия, когда скорости обработки на обоих концах системы не совпадают. Поскольку разница в скорости между процессором и памятью становится все больше и больше, люди в полной мере используют локальность данных и уменьшают влияние этой разницы, используя стратегию иерархии памяти.
Следовательно, данные, записанные в буфер, по-прежнему являются исходными данными, индекса нет, и поиск по ним невозможен. Только в Кэше можно.
Сравнение с MySQL, Cassandra, записью Mongo
В процессе записи базы данных необходимо записывать журнал операций, журнал набора реплик, а разные базы данных имеют разные методы обработки. Некоторые базы данных являются общими, а некоторые — отдельными.
Процесс записи журнала операций обычно записывается непосредственно на диск, поскольку он используется для восстановления данных, чтобы предотвратить потерю данных в памяти, вызванную простоем процесса и машины. Запись в буфер может привести к потере данных. так как эластичный поискmysql innodbЭтот тип буфера записи журнала операций также предоставляет элементы конфигурации, гарантирующие, что при успешном выполнении транзакции журнал операций будет очищен. ноesМинимальный флеш-диск журнала операций не может быть ниже100ms.
Ниже приведено сравнение журналов каждой базы данных, одна и та же функция, но каждый создатель имеет свой собственный стиль и должен иметь другое имя.
| база данных | запись журнала, сброс диска | Копировать журнал | Примечание |
|---|---|---|---|
| cassandra | commit log | commit log | журнал фиксации записывается непосредственно на диск |
| mongo | journal | oplog | журнал журнала пишет на диск |
| mysql | redo logs | bin log | буфер записи журналов повторного выполнения, |
| elastic search | translog | translog | буфер записи |
Заинтересованные студенты могут написать и проанализировать монго и кассандру, написанные ранее.
Обратите внимание на публичный аккаунт [Abbot's Temple], как можно скорее получите обновление статьи и начните путь технической практики вместе с аббатом
Ссылаться на
woohoo.elastic.co/expensive/en/bad…
Ралли TVC.files.WordPress.com/2018/05/boring…