Назад | Перейти на главную страницу

Масштабируемая архитектура базы данных для тяжелого чтения и тяжелой записи?

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

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

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

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

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

Здесь нет ничего отдаленно близкого к универсальному, но если вы хотите выйти за рамки традиционных решений для реляционных баз данных, то я предлагаю вам Google "NoSQL" и начать читать.

короткий ответ: шардинг

длинный ответ: вы либо разрабатываете свой собственный слой «nosql» поверх sql db (обычно mysql), либо используете один из многих популярных инструментов nosql (mongodb, cassandra, redis и т. д.).

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

Если вы можете подогнать свои данные к стандартным реляционным таблицам иначе, чем я бы рассмотрел NoSQL ..

Хранилище данных кластера с тяжелым стилем записи будет cassandra (NoSQL). Оно предназначено для неблокирующей записи ...: D

В противном случае .. Попытайтесь сегментировать с помощью SQL и, как иногда делают крупные компании, запустите mysql в главной <---> главной конфигурации ..

Какие типы данных записываются и читаются?