Какое значение ключа, база данных Nosql может гарантировать потерю данных при сбое питания?

Question

В настоящее время мы используем Redis в качестве оперативного кэша в памяти. Он работает хорошо. Проблема в том, что после перезапуска Redis нам нужно повторно заполнить ее, извлекая данные из нашего постоянного хранилища. Это перегружает наш постоянный магазин за его пределы, и, следовательно, восстановление занимает много времени.

Мы рассмотрели варианты сохранения Редиса. Лучшим вариантом (без ущерба для производительности) является использование AOF с «appendfsync everysec». Но с этой опцией мы можем потерять последние последние данные. Это неприемлемо. Использование AOF с «appednfsync always» имеет значительное снижение производительности.

Итак, мы оцениваем аэрозоль одного узла. Гарантирует ли это отсутствие потери данных при сбоях питания? В ответ на операцию записи, как только Aerospike отправляет клиенту успех, данные никогда не должны быть потеряны, даже если я вытащу кабель питания серверной машины. Как я упоминал выше, я считаю, что Redis может предоставить эту гарантию с опцией «appednfsync always». Но мы не рассматриваем его, так как он обладает значительным штрафом за производительность.

Если Aerospike может это сделать, я хотел бы детально понять, как упорство работает в Aerospike. Поделитесь некоторыми ресурсами, объясняя то же самое.

Мы не ищем распределенную систему, так как для нас необходима сильная консистенция. Данные не должны быть потеряны при сбоях узлов или разделить мозговые сценарии.

Если вы не являетесь косметологом, можете ли вы указать мне на другой инструмент, который может помочь в достижении этого?

Answer 1

Я считаю, что aerospike бы служит ваша цель, вы можете настроить его для гибридного хранилища в пространстве имен (т.е. DB) уровень в aerospike.conf , который присутствует в /etc/aerospike/aerospike.conf

для получения дополнительной информации, пожалуйста, смотрите официальную документацию здесь: http://www.aerospike.com/docs/operations/configure/namespace/storage/

Answer 2

я работаю Aerospike. Вы можете использовать пространство имен, хранящееся в памяти, на диске или в памяти с сохранением диска. Во всех этих сценариях мы делаем выгодно по сравнению с Redis в реальных тестах.

Принимая во внимание хранение на диске, когда происходит запись, он попадает в буфер перед тем, как его сбросят на диск. Ack не возвращается к клиенту, пока этот буфер не будет успешно записан. Правдоподобно, что если вы выдержите кабель питания до сброса буфера, в кластере с одним узлом запись может быть вызвана клиентом и впоследствии потеряна.

Ответ должен состоять из нескольких узлов в кластере и replication-factor> = 2. Запись затем переходит к буферу на клиенте и реплике и должна преуспеть на обоих перед тем, как быть успешным для клиента , Если питание вытягивается с одного узла, копия все еще будет существовать на другом узле, и никакие данные не будут потеряны.

Итак, да, можно сделать Aerospike устойчивым, так как разумно быть дешевым с минимальными задержками. Самое лучшее, что нужно сделать, это загрузить издание сообщества и посмотреть, что вы думаете. Я подозреваю, вам понравится.

Answer 3

Я полагаю, что вы будете во власти латентности любого носителя данных или латентности сетевой ткани в случае кластера, независимо от того, какую технологию СУБД вы используете, если у вас есть гарантия того, что данные не будут потеряны. (НотабенеРешение Бена Бейтса не будет работать, если есть вероятность, что вся физическая установка теряет силу, то есть оба узла теряют власть. Но я бы подумал, что недорогой ИБП существенно, если не полностью, смягчит эту проблему.) И эти задержки приведут к резкому снижению производительности вставки/обновления/удаления по сравнению с автономным экземпляром базы данных в памяти.

Другим вариантом является использование хранилища NVDIMM для базы данных в памяти или для журнала транзакций с записью, который использовался для восстановления. Он будет иметь абсолютную низкую задержку (сравнимую с обычной DRAM). И если ваша база данных в памяти будет вписываться в доступную память NVDIMM, у вас будет самое быстрое восстановление (нет необходимости переигрывать из журнала транзакций) и сопоставимой производительности с исходной производительностью IMDB, потому что вы вернулись к одному write и 2+ для добавления журнала записи и/или репликации на другой узел в кластере. Но ваша система базы данных в памяти должна поддерживать прямое восстановление базы данных в памяти (а не только из журнала транзакций). Но, опять же, два требования для этого варианта: 1. Вся база данных должна вписываться в память NVDIMM. 2. Система базы данных должна поддерживать восстановление базы данных сразу после перезапуска системы, без журнала транзакций ,

Еще в этой белой бумаге http://www.odbms.org/wp-content/uploads/2014/06/IMDS-NVDIMM-paper.pdf

Answer 4

Это не проблема базы данных, это аппаратная проблема и риск.

Все базы данных (имеющие постоянство) работают одинаково, некоторые записывают данные непосредственно на физический диск, а другие сообщают операционной системе о его записи. Единственный способ гарантировать безопасность каждой записи - это подождать, пока диск не подтвердит, что данные записаны.

Нет никакого способа обойти это, и, как вы видели, это значительно снижает пропускную способность. Вот почему базы данных используют буфер памяти и записывают партии данных из буфера на диск через короткие промежутки времени. Однако это означает, что существует небольшой риск того, что проблема с машиной (мощность, сбой диска и т. Д.) Происходит после того, как данные будут записаны в буфер, но до того, как они будут записаны на диск, это приведет к потере данных.

На одном сервере вы можете купить защиту через несколько источников питания, резервное копирование батареи и другие меры предосторожности, но это очень сложно и дорого. Вот почему распределенные архитектуры настолько распространены сегодня как для доступности, так и для резервирования. Распределенные системы не означают, что вы теряете согласованность, скорее они могут помочь обеспечить ее, защищая ваши данные.

Самый простой способ решить вашу проблему - использовать базу данных, которая позволяет выполнять репликацию, чтобы каждая запись выполнялась как минимум на 2 разных компьютерах. Таким образом, одна потеря компьютера может не повлиять на запись на другую машину, и ваши данные по-прежнему безопасны.

Вам по-прежнему необходимо защититься от перебоев с подачей электроэнергии на более высоком уровне, который может повлиять на все серверы (например, весь ваш центр обработки данных), но вы можете решить это, распределив все границы. Все зависит от того, какой уровень риска вам подходит.

Между настройкой интервалов записи на диск в вашей базе данных и использованием надлежащей распределенной архитектуры вы можете получить необходимые требования к последовательности и производительности.