Что такое TOO BIG для базы данных?

Question

У меня есть приятель, который запускает веб-приложение для людей, перечисляющих автомобили для продажи. Есть несколько тысяч клиентов, которые его используют, и каждый клиент имеет сотни, а иногда и тысячи строк в базе данных (некоторые из них работают в течение 5 лет с сотнями автомобилей, продаваемых каждый месяц, и 10 с строк за продажу (комментарии, сообщения, и т.д)). Он запустил эту систему в одной базе данных SQL Server на одном физическом сервере с 20 ГБ или ОЗУ и нескольких процессорах на все время без проблем. Это какое-то чудо?

Как и большинство программистов, я не являюсь администратором баз данных и просто прохожу благодаря ORM и т. Д. Везде, где я смотрю, люди говорят о необходимости очертить или получить отдельный сервер базы данных для крупных пользователей веб-приложения , Почему это? Неужели это неэффективно иметь большую БД с партиями или рядами? Должен ли я планировать использовать Cassandra или что-то в этом роде, или могу ли я рассчитывать на то, чтобы хорошо масштабировать Postgres?

Answer 1

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

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

Answer 2

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

Answer 3

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

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

Answer 4

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

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

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

Answer 5

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

Answer 6

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

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

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

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

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