Что СЛИШКОМ БОЛЬШОЕ для базы данных?

Я лично не думаю, что то, что вы описали, является такой большой базой данных. Сервер (20 гигов оперативки? ;)) звучит прилично. Это больше касается использования и дизайна. Если база данных проиндексирована и хорошо спроектирована, она может значительно увеличиться на существующем оборудовании.

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

Причина шардинга и отдельных серверов БД заключается в том, что в какой-то момент будет дешевле использовать несколько более дешевых машин, чем одну дорогую. Цена на оборудование не зависит от производительности линейно, и как только вы достигнете определенной точки, будет намного дешевле получить в два раза больше машин, чем получить машину, которая вдвое быстрее.

У вас не должно возникнуть проблем с SQL-сервером, Oracle или любой современной реляционной или нереляционной базой данных. Я администрировал базы данных с сотнями миллионов записей и терабайтами данных.

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

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

Разделив веб-сайт или приложение по разным серверам, проще получить более дешевые машины и их больше. Таким образом, вы можете создать отказоустойчивость и не иметь компонентов, предъявляющих аналогичные требования к аппаратным конфликтам.

Также важно подумать о времени восстановления серверов и планах восстановления.
Что произойдет, если ваша машина выйдет из строя, сможете ли вы заменить ее в оговоренное время? Можно ли за это время восстановить из резервных копий?

SQL Server или другие базы данных корпоративного класса не должны иметь проблем с базами данных 10 или 100 ГБ, если они не слишком плохо спроектированы. (У нас есть несколько машин с такой мощностью/использованием, которые вообще не борются.).

По-моему, это ничего. Наличие десятков миллионов строк в нескольких таблицах с размером базы данных, превышающим 10 ГБ, не вызвало проблем для MS SQL Server. Конечно, это не слишком быстро с таким количеством данных, но в остальном работает нормально.

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

Базы данных чрезвычайно эффективны при хранении и извлечении реляционных данных (то есть данных, которые структурированы и имеют ссылки на другие данные) — для этого они и предназначены. Честно говоря, 99% людей, болтающих о хранилищах ключ-значение, Кассандре и прочем, понятия не имеют, что они делают. Сервер базы данных отлично подходит для хранения больших объемов данных, особенно если вы готовы немного поработать над его правильной настройкой.

Тем не менее, есть варианты использования Cassandra et. др. - если у вас в основном неструктурированные данные типа "ключ-значение" или вам не нужна согласованность или вы хотите сегментировать для избыточности, возможно, стоит изучить.

Если вы не являетесь чрезвычайно популярным веб-сайтом, вы, вероятно, вполне сможете обойтись приличным сервером базы данных — не переключайтесь, пока не определите, почему вам нужно переключиться. Переключение — это нормально, просто убедитесь, что вы переключаетесь, потому что это лучше отвечает вашим потребностям, а не потому что это «крутая вещь в веб-масштабе».