Успешные реализации VoltDB

Я работаю над проектом уже более полугода, создавая программное обеспечение для здравоохранения с нуля. Когда я присоединился, MySQL был выбран в качестве основного хранилища данных.

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

Мы рассмотрели множество решений NoSQL; MongoDB привлекает больше всего нашего внимания. Возможность хранения структурированных встроенных данных будет огромной выгодой. Тем не менее, мы были отпугнуты сообщениями о проблемах потери/надежности данных.

Я столкнулся с несколькими хранилищами данных "NewSQL", и я заинтересован, в частности, в VoltDB.

Мне любопытно узнать, есть ли у кого-нибудь опыт работы с Volt или видел, что он реализован в проекте.

Edit:

Наиболее важны целостность и согласованность данных. Это может быть очень вредно для информации пациентов теряться, они могут получить неправильное лечение и т.д.

Объем данных будет меняться; мы, скорее всего, будем поддерживать небольшие практики. Что-то вроде 700 пользователей всего. Но даже когда мы приближаемся к больницам, мы не смотрим на социальные сети, такие как трафик.

Что касается вашего вопроса, да, структуры данных будут развиваться. Помимо необходимости изменения существующей структуры для захвата новых или измененных входов, мы должны сохранить структуру существующих данных как своего рода оснастку. Мы только смогли сделать этот стиль EAV с MySQL.

Спасибо за ваши отзывы.

Ответ 1

Мы поехали в прошлом году с приложением, которое использует VoltDB. Мы храним около 1,5 миллиарда записей и обрабатываем 50-90 миллионов транзакций в день с кластером kfactor = 1 4 (256 ГБ памяти/сервером). Учитывая производительность VoltDB, мы могли бы легко передавать 1 миллиард транзакций в день.

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

Другие сильные функции включают его масштабируемость (и относительную простоту, чтобы добавить емкость).

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

Наконец - примечание относительно хранимых процедур. VoltDB позволяет заменить хранимые процедуры без остановки базы данных. Кроме того, каждый вызов хранимой процедуры представляет собой одну транзакцию. Мы использовали хранимые процедуры таким образом, чтобы мы могли модифицировать/обновлять нашу прикладную логику, не останавливая базу данных.

Ответ 2

Вопрос, поскольку он стоит, очень субъективен, но дополнительная информация может помочь нам указать вам в правильном направлении.

Каковы ваши требования? Имеет ли эта система транзакционные потребности, когда целостность и согласованность данных имеют первостепенное значение, например, в торговых и финансовых приложениях? Каков объем данных и сколько одновременно работающих пользователей? Каковы требования к производительности?

Кроме того, вы упомянули ever-changing healthcare data, означает ли это, что структуры данных постоянно меняются и развиваются? Если это так, вы можете остаться в стороне от реляционных баз данных, учитывая природу жестких схем и вместо этого рассмотреть хранилища документов, такие как Mongo, где структура данных с косой структурой обеспечивает большую гибкость.

Кстати,

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

VoltDB, последний, который я проверил, требует, чтобы вся логика сохранения была закодирована как хранимые процедуры. Очевидными недостатками этого подхода является меньшая видимость кода и модульность, а также более высокие потребности в обслуживании. Помимо этого, Voltdb работает очень быстро, так как большая часть накладных расходов, найденных в традиционных реляционных базах данных, таких как блокировка и т.д., Исключается из ядра базы данных.

Ответ 3

Вопрос немного стар, но я даю некоторую обратную связь, потому что мы долгое время используем MongoDB, и мы смотрим на VoltDB, но по совершенно другим причинам:

Относительно mongoDB: мы используем mongoDB в производстве с 4 лет, и мы никогда не теряли ни одного байта данных. "Mongodb не является надежным", кажется, мифом, по крайней мере для меня. Мы каждый день управляем миллионами новых записей в mongoDB без проблем.
Мы смотрим на VoltDB для другого варианта использования: предоставление аналитики в реальном времени на огромном объеме. MongoDB неплохо предоставляет аналитику, но когда вы выходите за пределы миллионов записей, которые нужно проанализировать, это начинает немного медленнее. VoltDB намного лучше, но я бы не советовал вам использовать его для хранения данных, особенно для данных с высоким значением.... Мы используем другую базу данных для хранения данных.