Post on 06-Apr-2017
transcript
ночью через лес: stress-test пяти almost-the-
same-functionality shared-nothing-cluster
NoSQL СУБД
Здравствуйте,меня зовут Даниил,я системно администирую уже 20 лет и у меня проблема
откуда вообще взялась эта идея1. Данные надо где-то хранить2. РСУБД работают хорошо.
1. Пока нам не нужна репликация2. И шардинг
3. Распределенные СУБД1. Они нам нравятся
1. Потому что мы ленивые2. Но работают они как-то странно
1. особенно когда нам по-настоящему надо, чтобы они работали хорошо
3. и нельзя сказать, что нас не предупредили
Чего мы собственно хотим
● У нас есть чтения и записи● Чтения должны происходить надежно● Данные должны храниться надежно● Объем хранилища должен наращиваться
горизонтально● все это должно быть ДЕШЕВО
Методика тестирования1. создаем кластер из 5 нод2. заливаем с максимально возможной скоростью записи в базу3. запускаем процесс случайного чтения
a. с того же сервера запускаем писателя4. имитируем сбой одной из нод5. наблюдаем за поведением кластера, читателей и писателей6. из ранее удаленной ноды создаем новую и возвращаем ее в кластер7. наблюдаем за поведением кластера, читателей и писателей до полного восстановления
кластера8. добавляем в кластер еще одну ноду9. наблюдаем за поведением кластера, читателей и писателей10. Узнать мы хотим о сюрпризах, которые готовит нам эксплуатация продукта в
экстремальных условияхa. а все остальное нас интересует постольку-посколькуb. некоторые кандидаты закончили тестирование на этапе чтения документации
Отбор кандидатов● Источник вдохновения: http://nosql-database.org/● aerospike● cassandra● crate.io● elasticsearch● orientdb● rethinkdb● где RIAK?!● Но обзор будет анонимным
Тестовая среда
● 5-6 машин для кластераo RAID0, кеширование записи
● Выделенная машина для клиента записи-чтения● Выделенная машина для Grafana● Выделенная гигабитная сеть - и, забегая вперед,
сеть должна бы быть получше● docker как метод деплоя
Продукт A
Продукт A
● Поначалу все хорошо● Потом все похуже● А вот мы выключили ноду - и где же все?!● А вот кластер проснулся
Продукт B
оказался надстройкой над продуктом A в смысле технологий репликации и шардинга
Продукт C
● Выглядит многообещающе● “Думайте обо мне как о массиве дисков”● Но как делать ребалансинг?!● И куда попадают новые ноды?!!
Продукт D
Продукт D● Поначалу все хорошо● И потом все хорошо● А вот мы выключили ноду. Пришлось перезапустить
чтение.● А вот мы вернули ноду в строй● А вот мы добавили шестую машину● Похоже, это идеальный кандидат
o но при дефолтных настройках ребалансинг очень медленный
Продукт Е
Продукт Е
Продукт Е● Поначалу все хорошо● И потом все хорошо
o Но к концу появляются ошибки записи. Их мало, они не видны на графике
● Вот мы выключили ноду - все, вроде, хорошо● А вот мы ее включили. Откуда эти ошибки чтения?!
o Прежде, чем включать ноду на том же IP - надо поприседать вокруг конфигов
o И вообще - ребалансинг представляет собой нетривиальную задачу
Продукт F
Продукт F● Какой хороший GUI!● И поначалу все хорошо● А потом похуже● А почему все данные в одном шарде?!
o Ну давайте попробуем использовать SHA1 в качестве primary key● Стало лучше - теперь данные распределены по двум шардам. Из
пяти…● Картинки не будет - как только я собрался ее снять, кластер упал● Совсем упал - запустить его опять не удалось за приемлемлемое
время
Деанонимизация
A - ElasticSearchB - Crate.IOC - AerospikeD - OrientDBE - CassandraF - RethinkDB
Выводы
● Как страшно жить● Будем делать на Aerospike