ночью через лес: 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