Как вы проектируете массивный дизайн БД? - PullRequest
1 голос
/ 21 июля 2011

Это всего лишь вопрос дизайна относительно массивного дизайна БД.Например, если вы собираетесь создать базу данных, которая будет содержать 10 миллионов пользователей, как бы вы ее разработали?

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

При создании БД такого размера, скажите, что поля имеют имя «username» «name» «company» »Доб, "пол", кроме составления одной таблицы, в таком масштабе, что еще следует учитывать?Индексы

Ответы [ 3 ]

3 голосов
/ 21 июля 2011

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

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

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

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

0 голосов
/ 21 июля 2011

Как всегда, это зависит от вариантов использования .. какие запросы вы собираетесь запускать в базе данных?

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

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

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

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

0 голосов
/ 21 июля 2011

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

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

...