Вопрос по mysql, database, sql – NewSQL против традиционной оптимизации / шардинга [закрыто]

11

Мы являемся небольшим стартапом с приложением 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   ответа
0

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

1

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

0

ово при масштабировании, написании тяжелых приложений и в облаке AWS. Варианта хостинга нет, поэтому наши разработчики владеют им, и они тратят & lt; 1 час в неделю администрирование нашего кластера VoltDB. На самом деле мы используем RDS и VoltDB. RDS для нашей традиционной реляционной рабочей нагрузки и VoltDB для обработки транзакций ВЫСОКОГО ОБЪЕМА. Если вы разрабатываете на Java, VoltDB отлично подходит для написания всех процедур на Java.

Похожие вопросы