Лучшие практики для структурирования базы данных для масштабирования

Question

Я знаю, что это очень общий и субъективный вопрос, поэтому не стесняйтесь голосовать, чтобы закрыть его, если он не соответствует этикету StackOverflow ... но для меня это стоит попробовать;)

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

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

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

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

Редактировать some detail о моем приложении:

1. Приложение будет работать как многосайтовое поведение
2. У меня будет база данных для каждой версии приложения (db_0_0_1, db_0_0_2 и т. д.) *
3. Каждый «сайт» будет иметь схему внутри базы данных * и роль, которая может получить доступ только к его собственным схемам
4. Код приложения будет в основном PHP и несколько вещей (демонов и вещей обслуживания) в Python
5. Веб-сервер, вероятно, будет Nginx и lighttpd или node.js в качестве поддержки для задач с длительным опросом (например, чата)
6. Кэширование будет выполняться с memcached (плюс apc для вещей, строго связанных с phpкод, как его можно использовать вне php)

Answer 1

Вопрос действительно общий, но вот несколько советов:

• Не используйте переменные сеанса (pg_backend_pid (), inet_client_addr ()) или управление для сеанса (SET ROLE, SET SESSION) в коде приложения.

• Не используйте явный контроль транзакций (BEGIN / COMMIT / SET TRANSACTION) в коде приложения.Вся такая логика должна быть заключена в UDF .Это позволяет без сохранения состояния , пул в режиме оператора, который позволяет максимально быстро пул БД.(см. pgbouncer docs и pg wiki для получения дополнительной информации)

• Инкапсулируйте всю связь App <-> Db в четко определенном API БДUDFs - это позволит вам использовать PL / Proxy.Если делать это со всеми SELECT слишком сложно, сделайте это по крайней мере для всех операций записи данных (INSERT / UPDATE / DELETE).Пример: вместо INSERT INTO users(name) VALUES('Joe') вам нужно SELECT create_user('Joe').

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

• подумайте о кэшировании, прежде чем оно понадобится.какой будет ключ кеширования?какой будет таймаут кеша?вы будете использовать memcached?