Какие серверы я должен использовать для своего приложения? (MySQL DB и Sphinx 300 ГБ) [дубликат]
Возможный дубликат:
Вы можете помочь мне с планированием мощности?
Я написал приложение, которое использует MySQL и Sphinx для поиска и хранения информации.
приложение содержит базу данных размером 300 ГБ (в основном текст, средний текст и символы var). мой индекс sphinx весит 30 ГБ.
Моя проблема была сформулирована, когда я планировал использовать БД на 100 ГБ, а теперь у меня есть БД на 300 ГБ, которую нельзя загрузить в память (?).
Я ищу лучшую архитектуру, которая обеспечит максимальную производительность.
мое приложение сначала получает запрос, затем запускает его по индексу sphinx, получает большую часть идентификаторов от sphinx, запрашивает у БД несколько текстовых полей для этих идентификаторов и отправляет результаты в средство ранжирования .NET (специальный алгоритм).
Чтобы добиться максимальной производительности, я использовал сервер Xeon i7 W3520 с 2 дисками SSD (оперативная память 24 ГБ) для MySQL, это не дешево, и мне не хватает места, и я не могу добавить больше дисков, поэтому мне нужен другой сервер.
Как вы думаете, сильно ли повлияет на производительность, если я буду использовать сервер с обычными дисками для mysql? Я знаю, что мне нужны быстрые диски для поиска сфинкса (это моя система полнотекстового поиска), я использую индексированное поле (ID) для выбора строк из БД без каких-либо сложных запросов, мне может потребоваться разместить БД на более дешевый сервер с достаточным объемом памяти.
Вы можете определить мое узкое место? приложению .NET требуется в основном ОЗУ и ЦП, БД требуется много места и / или ОЗУ, а сфинксу нужны быстрые диски и ОЗУ.
- Можно ли загрузить индекс MySQL в ОЗУ?
- Что я могу сделать, чтобы уменьшить тот факт, что размер БД 300 ГБ?
- Будет ли сервер с более медленными дисками сильно влиять на производительность? (Я не могу протестировать его, не потратив сотни долларов на оборудование).
- имеет ли значение, использую ли я Linux или Windows для MySQL?
Я ищу лучшую архитектуру, которая даст мне максимальную производительность.
Какой здесь вопрос? Не поймите меня неправильно, но есть только ОДИН способ сделать это - разместить базу данных на самом быстром SSD из возможных.
Может ли это иметь смысл? Понятия не имею, но вы просите не о достаточно быстром сценарии, а о САМОЙ ВЫСОКОЙ производительности.
и теперь у меня есть 300 ГБ, который не может быть загружен в память (?).
Знаете, это не правда. Сервер на 512 ГБ не особенно велик по сегодняшним стандартам.
будет ли сервер с более медленными дисками сильно влиять на производительность?
Конечно, будет. Обычно количество операций ввода-вывода в секунду (производительность ввода-вывода) является ограничивающим фактором для базы данных, когда база данных не загружена в оперативную память.
Как вы думаете, будет ли значительное влияние на производительность, если я ' Будете использовать сервер с обычными дисками для mysql? I
Определите «обычный диск». Массив дисков SAS 15k RPM является «обычным» для высокопроизводительной базы данных, каждый диск примерно в 3-4 раза больше IOPS, чем ваш обычный диск, но затем ... с такой МАЛЕНЬКОЙ базой данных поместите его в SSD 512 ГБ и получите 50 000 операций ввода-вывода в секунду вместо 500 или около того, что дает диск SAS 15 КБ.
БД требуется много места и / или ОЗУ, а сфинксу нужны быстрые диски и ОЗУ.
ЛЮБАЯ база данных, которая не заполняет все данные from RAM ограничивается дисками нормально, в основном потому, что диски ужасно МЕДЛЕННО МЕДЛЕННО МЕДЛЕННО. Самая быстрая дисковая подсистема является стандартной при установке больших баз данных, но у вас небольшая база данных, поэтому достаточно простого SSD. К сожалению, это ВСЕ ЕЩЕ намного меньшая производительность, чем RAM.
Что я могу сделать, чтобы смягчить тот факт, что БД ' размер s если 300GB?
Понимаете, это крошечный? У меня дома есть база данных на 850 ГБ, а моим последним проектом была база данных на 21000 ГБ. В зависимости от того, что я делаю с некоторыми данными, к которым у меня есть доступ сейчас, я получаю 44000 ГБ сильно сжатых данных, которые мне нужно будет обработать. 300 ГБ - это мало для "получения памяти".
имеет ли значение, использую ли я Linux или Windows для MySQL?
Может быть, но это совершенно не имеет отношения к Этому вопросу. Windows может иметь - в зависимости от конфигурации - большие накладные расходы, но это не имеет значения. Когда вы имеете дело с такими системами, то жесткое указание дополнительных 128M накладных расходов не имеет никакого значения.
Я получаю 44000 ГБ сильно сжатых данных, которые мне нужно обработать. 300 ГБ - это мало для "получения памяти".имеет ли значение, использую ли я Linux или Windows-машину для MySQL?
Может быть, но это совершенно не имеет отношения к Этому вопросу. Windows может иметь - в зависимости от конфигурации - большие накладные расходы, но это не имеет значения. Когда вы имеете дело с такими системами, то жесткое указание дополнительных 128M накладных расходов не имеет никакого значения.
Я получаю 44000 ГБ сильно сжатых данных, которые мне нужно обработать. 300 ГБ - это мало для "получения памяти".имеет ли значение, использую ли я Linux или Windows-машину для MySQL?
Может быть, но это совершенно не имеет отношения к Этому вопросу. Windows может иметь - в зависимости от конфигурации - большие накладные расходы, но это не имеет значения. Когда вы имеете дело с такими системами, то жесткое указание дополнительных 128M накладных расходов не имеет никакого значения.
знаете ли вы, что делает ваш сервер, знаете ли вы, где узкие места в производительности? если у вас нет какого-либо мониторинга и отслеживания тенденций, вы слепы.
Может быть, вам может помочь простое добавление правильной индексации данных?
Возможно, ввод-вывод действительно является вашим пределом, но, возможно, у вас много свободных циклов ЦП, и простое сжатие больших двоичных объектов, хранящихся в базе данных, может увеличить попадание в кэш памяти ratio за счет [де] сжатия на лету, что, вероятно, будет незаметно.
Я бы сказал, что запуск mysql / sphinx под Linux даст вам больше шансов увидеть и отследить, «что происходит внутри».