Десяток не нужен, но нужно 4-5, для распределения нагрузки и защиты, сам сайт крутится на одном сервере ( назовем его слейв1), он и является пабликом, его же в основном и дидосят и используют юзеры для чтения, на него мы реплицируем данные для чтения.
На другом(назовем его мастер2) почти тупо запись в больших объемах, и примерно 10% чтения для записи, с него реплицируем данные, которые использует слейв1).
Третий и четвертый сервак (назовем их слейвами 3 и 4) для определенных задач скриптов, в результате работы этих скриптов, часть данных отправляется на мастер2.
Пума Тайланд: сорри за тупой вопрос если есть мастер слей следовательно есть слейв мастер? Думаю да. 245 млрд если сделать их в несколько байт (а у нас возможно сделать до 10-15 байт значения).
Что касается размеров теоретически, с учетом озвученного обьема данных, по моим подсчетам это 40 gb данных примерно, и честно говоря на опыте это чуть больше в размере ddr чем я озвучил., так случилось на моей работе. И честно говоря я не хочу повторения событий, в которых производительность прямо пропорционально размеру ddr, притом , если кто сам покупал серверную ddr, тот знает нереальную цену такого рода "масштабированию"))).
Структура бд проста. Выбираем id читаем, в течение минуты выясняем результат, асинхронно, результат пишем. Таких выборок 100 тыс в минуту, на 1 сервер. Сложные выборки на чтение и "медленную" запись, под медленной понимается сложная выборка пользователем, как правило не чаще раз в сути, тут идеален мускул, по многим причинам.
Кстати как вы думаете, по идее если редис поставить на сервер где запись, а потом реплицировать на второй сервер где редкое чтение, их возможно подружить на уровне данных? Теоретически, на уровне данных на раз два.
Nosql и все красивые слова мы знаем. Единственное я не владею ключ-значение, но не суть, как я понимаю +- это то что нам может подойти, с учетом того что сложных выборок нет.
Имеются значения в год я посчитал мы записываем 245> миллиардов записей. Разделить не сложно. Основано именно на опыте, а не на теориях.
Попробую скорр скинуть структуру и запрос.
Я согласен, что мускул это в первую очередь проект с опытом, и был у меня опыт с 40gb данными highload, но там я грешил всегда на оптимизацию запросов и перепроектирование. Но всегда считал, что от перехода зеркального на оракл, ничего не изменится.
Написано
Войдите на сайт
Чтобы задать вопрос и получить на него квалифицированный ответ.
На другом(назовем его мастер2) почти тупо запись в больших объемах, и примерно 10% чтения для записи, с него реплицируем данные, которые использует слейв1).
Третий и четвертый сервак (назовем их слейвами 3 и 4) для определенных задач скриптов, в результате работы этих скриптов, часть данных отправляется на мастер2.