NewSQL против традиционной оптимизации / шардинга [закрыто]

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

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

Scaling. This is the biggest concern. We currently run an XL RDS instance. We'll be able to get by for a while longer with straightforward optimizations, but unless we make some major structural changes to our app, we'll hit a bottleneck at some point.

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

Availability. We run a multi-AZ instance, so we should survive a single AZ outage. But RDS is built on EBS, which makes me pretty worried given EBS's history and design.

Price. Our RDS bill is 4x what we pay Heroku. I don't mind paying Amazon to save me from hiring a sysadmin, but I would love to find something less expensive.

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

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

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

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

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

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

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

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

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

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

Ответы на вопрос(3)

Ваш ответ на вопрос