База данных должна иметь возможность масштабирования и без сбоев или задержек.

Поставщики программного обеспечения, перемещающиеся в бизнес-модель SaaS, обычно оптимистично оценивают перспективы продукта (ов) и компании. Вложение инвестиций в такое изменение подразумевает надежду на рост.

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

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

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

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

База данных облака должна иметь возможность масштабирования и без сбоев или задержек. Если для масштабирования требуется несколько часов или дней (в типичной реляционной базе данных это означает вверх или вниз) или создает сбой для миграции или перераспределения, одно из основных преимуществ теряется. Чем более зернистый рост кластеров и чем меньше подход «ступенчатой ​​лестницы» к ресурсам, тем более эластичным является решение.

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

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

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

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