Лучшие практики структурирования базы данных для обеспечения готовности к масштабированию
Я знаю, что это очень общий и субъективный вопрос, поэтому не стесняйтесь голосовать за его закрытие, если он не соответствует этикету StackOverflow... но для меня это стоит попробовать ;)
Я никогда не создавал приложения с высоким трафиком, поэтому я не знаю (кроме некоторого чтения в Интернете) о практике масштабирования.
Как я могу спроектировать базу данных, чтобы при необходимости масштабирования мне не пришлось рефакторить структуру базы данных или код приложения?
Я знаю, что разработка (и оптимизация) должна идти шаг за шагом, оптимизируя узкие места по мере их возникновения, и практически невозможно спроектировать идеальную структуру, когда вы не знаете, сколько у вас будет пользователей и как они будут использовать базу данных (например, соотношение чтения и записи), я просто ищу хорошую базу для начала.
Каковы лучшие практики для создания структуры, почти готовой к масштабированию с разделением и шардингом, и каких хаков следует избегать?
Редактировать некоторые детали о моем приложении:
- Приложение будет работать как многосайтовое поведение
- У меня будет база данных для каждой версии приложения (db_0_0_1, db_0_0_2 и т.д.. *
- Каждый "сайт" будет иметь схему внутри базы данных* и роль, которая может получить доступ только к своим собственным схемам
- Код приложения будет в основном PHP и несколько вещей (демоны и обслуживание) на Python
- Веб-сервер, вероятно, будет Nginx и lighttpd или node. js в качестве поддержки для задач с длительным опросом (например, чат)
- Кэширование будет осуществляться с помощью memcached (плюс apc для вещей, строго связанных с php-кодом, поскольку он может использоваться вне php)