NewSQL против традиционной оптимизации/ошпаривания

Мы небольшой запуск с помощью приложения SAAS для записи и (наконец!), доходя до того момента, когда наше использование приводит к проблемам масштабирования. У нас небольшая команда, поэтому мы очень ценим возможность разгрузить системный администратор для Heroku и RDS.

В то время как Heroku (в основном) прекрасен, у нас есть пара проблем с RDS:

  • Масштабирование. Это самая большая проблема. В настоящее время мы запускаем экземпляр XL RDS. Мы сможем провести некоторое время с простой оптимизацией, но, если мы не сделаем некоторые существенные структурные изменения в нашем приложении, в какой-то момент мы столкнемся с узким местом.

Кроме того, время простоя для изменения размера экземпляра отстой.

  • Наличие

    . Мы запускаем мульти-AZ-экземпляр, поэтому нам нужно выжить в одном отключении AZ. Но RDS построен на EBS, что заставляет меня очень беспокоиться, учитывая историю и дизайн EBS.

  • Цена. Наш счет RDS составляет 4 раза, что мы платим Heroku. Я не против платить Amazon, чтобы спасти меня от найма администратора, но я хотел бы найти что-то дешевле.

На мой взгляд, у нас есть два варианта продвижения вперед: традиционный подход (очертание, запуск ночной работы для перемещения частей нашей базы данных на чтение и т.д.); или решение NewSQL (Xeround, VoltDB, NimbusDB и т.д.).

Традиционные профи: это делалось много раз раньше, и есть довольно стандартные способы сделать это.

Традиционные минусы: это займет много работы и внесет значительную сложность в приложение. Это также не решит вторичные проблемы с RDS (доступность и цена).

Преимущества NewSQL: предположительно, эти решения будут горизонтально масштабировать нашу базу данных без изменения кода приложения (с учетом нескольких ограничений на функциональность SQL, таких как использование пессимистической блокировки). Это сэкономит нам огромную работу. Это также повысит надежность (без единой точки отказа) и уменьшит затраты (не имея возможности запуска экземпляра XL в нерабочее время, чтобы обеспечить максимальное использование).

NewSQL минус: эти решения относительно молоды, и я не смог найти хороших отзывов или рецензий людей, которые с ними сталкиваются в производственных приложениях. Я нашел только один доступный хостинг-решение (Xeround), поэтому, если мы не поедем с ним, нам придется инвестировать ресурсы в sysadmin.

Мне интересно, какие мнения о том, каким будет мой лучший вариант.

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

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

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

Заранее благодарим за ваши мысли.

Ответ 1

Не уверен, что вы еще слышали о NuoDB. Но это совершенно новое решение для SQL, которое предлагает возможности масштабирования возможностей NoSQL и SQL и ACID традиционного OLTP. Вы должны взглянуть на решение.

Ответ 2

В Jingit (www.jingit.com) у нас есть боевые испытания VoltDB. Это фантастика при масштабировании приложений для записи тяжелых приложений и в облаке AWS. Нет хостингового варианта, поэтому наши разработчики владеют им, и они тратят < 1 час в неделю, управляя нашим кластером VoltDB. Фактически мы используем RDS и VoltDB. RDS для нашей традиционной реляционной рабочей нагрузки и VoltDB для обработки транзакций HIGH VOLUME. Если вы разрабатываете Java, VoltDB отлично подходит для написания всех процедур на Java.

Ответ 3

Я тоже слышу, что NuoDB интересен. Одна вещь, которую я слышу, - это то, что Rackspace вскоре появится с облачным DBaaS. Я не знаю, какой вкус они будут использовать, но вы могли видеть, как Nuo работает как масштабируемое решение с ними. Я думаю, что он будет работать вместе с платформой Open Stack, которая, когда они откроют ее, может быть более эффективной и экономичной. Просто то, что я сам наблюдал.