Полагаю, это отчасти субъективно, потому что, вероятно, это зависит от того, как все понимают «большой объем», но ради обсуждения я хотел бы подойти к этому гипотетически. Кроме того, если это что-то, что должно быть эксклюзивным для ServerFault, дайте мне знать, и я с радостью перепишусь там.
Очевидно, что существует множество хорошо известных серверов баз данных, наиболее похвальным из которых, вероятно, является MySQL. Многие люди клянутся SQLite, PostgreSQL или даже MSSQL (я по общему признанию использовал только MySQL и SQLite). У меня был большой успех в работе с MySQL для трафика с низким средним (<= 1 000 000 обращений / месяц), когда взаимодействие с базой данных было минимальным или умеренным (например, без сложных подзапросов, широких объединений и т. Д.), И кластерами MySQL для среднего и среднего уровня. высокий трафик. Тем не менее, я задаюсь вопросом о достоверности систем на основе файловых систем для чрезвычайно высокого трафика (скажем, 100 000 одновременных подключений, гипотетически). </p>
Всегда существует подход «построить что-то солидное, оптимизировать его, а затем масштабировать, добавляя больше процессоров», что не является необоснованным, учитывая облако, и я не обязательно боюсь порождать рабов, чтобы держать вещи в порядке. распределены. Но с точки зрения минимализма (и эффективности), для чего-то с таким количеством одновременных запросов, кажется, что добавление большего количества механизмов к машине просто добавляет ненужную сложность.
Я знаю, что использование чего-то вроде MySQL Cluster поддерживает перераспределение запросов между работающими ведомыми устройствами в случае сбоя одного, но если у вас было одно приложение, такое, что логическое разделение использования на отдельные серверы было невозможно, есть ли решение, более эффективное чем просто увеличение процессоров? Возможно использование хранилища файловой системы в точках монтирования N ? Я хотел бы получить некоторые мысли о плюсах и минусах.