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

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

Закрыт 7 лет назад.

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

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

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

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

Доступность. Мы запускаем инстанс в нескольких зонах доступности, поэтому мы должны пережить сбой в одной зоне доступности. Но RDS построен на EBS, что меня очень беспокоит, учитывая историю и структуру EBS.
Цена. Наш счет за RDS в 4 раза больше, чем мы платим Heroku.Я не против заплатить Amazon, чтобы избавить меня от найма системного администратора, но я хотел бы найти что-то менее дорогое.

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

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

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

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

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

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

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

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

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

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

задан Viccari 2 July 2012 в 11:04

0 ответов

Другие вопросы по тегам:

amazon-rds database mysql sharding sql

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

0 ответов

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