Comments 35
Как вы решаете проблему со скоростью системного диска? Где храните данные?
Чувствительные данные храним на подключаемых blob-storage дисках — там скорость выше. Если данные не критичные — то используем локальный диск. Кстати где-то на хабре недавно читал про use-case одного из проектов, где им удалось повысить производительность дисковой подсистемы путём «правильного» подбора параметров форматирования дисков. Это может быть интересно.
Прочел вашу статью но так и не понял, как у вас так получается:
это вроде бы даже близко не highload, с такими задачами вполне справиться средний сервер с несколькими дисками — парой ssd и hdd в разных рейдах (hdd под статику, ssd под бд/прочую динамику) + CDN сеть (услуги которых куда дешевле) еще и запас для роста будет. Стоить это естественно будет на порядки дешевле, но отказоустойчивость по сравнению с кластером конечно будет ниже.
Можете пояснить, как именно вам удается расходовать 140тыс рублей для подобной нагрузки?
Azure обходится нам сейчас в \~140 тыс. рублей в месяц. Этого нам хватает на 90%, так как для пиковых нагрузок всё же этого мало
в сутки он выдерживает ~2.5 тыс даров и ~1.5 тыс благодарностей, ~20 тыс. комментариев, ~40 тыс. уведомлений и ~4.5 тыс. файлов
это вроде бы даже близко не highload, с такими задачами вполне справиться средний сервер с несколькими дисками — парой ssd и hdd в разных рейдах (hdd под статику, ssd под бд/прочую динамику) + CDN сеть (услуги которых куда дешевле) еще и запас для роста будет. Стоить это естественно будет на порядки дешевле, но отказоустойчивость по сравнению с кластером конечно будет ниже.
Можете пояснить, как именно вам удается расходовать 140тыс рублей для подобной нагрузки?
UFO just landed and posted this here
А вы думаете в облаке azure знания как бы не нужны? Нажал кнопочку «сделать все хорошо» и все заработало? Отнюдь, хоть я имел и малый опыт работы с сервисами azure, но скажу вам заморочек там не меньше, чем в обслуживании рутованого сервера. Да и взгляните на текущих работников сферы «веб-разработка» — практически каждый достаточно неплохо (за некоторыми исключениями) может настроить рабочий сервер для разрабатываемого продукта (а многие еще и шишек граблями набили столько, что системные администраторы позавидуют ...).
По поводу суммы — если бы это было 14 тыс рублей я бы с вами согласился, но 140 тыс это, для меня лично, просто обдирательство, никак иначе (или владелец ресурса, рассматриваемого в данном посте, использует услуги azure из рук вон плохо и не рационально).
По поводу суммы — если бы это было 14 тыс рублей я бы с вами согласился, но 140 тыс это, для меня лично, просто обдирательство, никак иначе (или владелец ресурса, рассматриваемого в данном посте, использует услуги azure из рук вон плохо и не рационально).
использует услуги azure из рук вон плохо и не рационально
Да не, дело то не в этом, там ценник экспоненциально растет по добавлению ресурсов. Посмотрите их калькулятор\
https://azure.microsoft.com/ru-ru/pricing/details/virtual-machines/#Windows
После курса $ я, кстати, заметил, что не вижу комментариев к постам микрософта про ажуру на хабре вообще.
Согласен с Вами. Я когда прочёл эти цифры, тоже был удивлён, что подобное называют высокими нагрузками и что для этого прям так сильно нужно облако…
Загляните на их сайт. Если, в других частях проекта творится тоже самое, то удивляться нечему.
Текущая архитектура представлена в статье (на схеме). Всего в продакшене используется 11 инстансов (без тестовыx).
Самые толстые — под БД (3 шт), самые дешёвые — под почтой и кешем. Максимальная конфигуация — Standard_A7, минимальная — Standard_A2.
Примерно 15% стоимости уходит на оплату трафика.
Про CDN знаю и согласен, что можно при помощи него сэкнонмить и получить прирост по скорости загрузки статики, но пока голова и руки не дошли.
Признаться неясно что такое «средний сервер» и как он должен «справляться» в предлагаемой вами конфигурации. Есть ли какие-либо более явные примеры того, о чём вы говорите? Буду признателен.
Про «порядки» цен не согласен. Пересчитывали цены на collocation в Hetzner (правда в конце прошлого года) — получалось впритык (без запаса) примерно 1/3 текущей стоимости. И это только голое железо без какой-либо настройки. И как правильно заметили в комментарии, что грамотный специалист сейчас будет стоить прилично (сопоставимо с обсуждаемой конечной стоимостью).
PS: Вдруг подумал о том, чтобы в обозначенной цитате возможны разночтения. Тут речь идёт о кол-ве ежедневном приросте данных в сутки, а не общем их объёме. Верно?
Самые толстые — под БД (3 шт), самые дешёвые — под почтой и кешем. Максимальная конфигуация — Standard_A7, минимальная — Standard_A2.
Примерно 15% стоимости уходит на оплату трафика.
Про CDN знаю и согласен, что можно при помощи него сэкнонмить и получить прирост по скорости загрузки статики, но пока голова и руки не дошли.
Признаться неясно что такое «средний сервер» и как он должен «справляться» в предлагаемой вами конфигурации. Есть ли какие-либо более явные примеры того, о чём вы говорите? Буду признателен.
Про «порядки» цен не согласен. Пересчитывали цены на collocation в Hetzner (правда в конце прошлого года) — получалось впритык (без запаса) примерно 1/3 текущей стоимости. И это только голое железо без какой-либо настройки. И как правильно заметили в комментарии, что грамотный специалист сейчас будет стоить прилично (сопоставимо с обсуждаемой конечной стоимостью).
PS: Вдруг подумал о том, чтобы в обозначенной цитате возможны разночтения. Тут речь идёт о кол-ве ежедневном приросте данных в сутки, а не общем их объёме. Верно?
20000 в сутки — это 0.23 запроса в секунду. Я точно ничего не перепутал?
Лет 12 назад я занимался «хайлоадом». Пять серверов, по 200000 запросов на хост в сутки. Это только те, которые что-то меняли в БД — про статику и селекты сейчас не говорим. Сервера были средненькие и по ощущениям проглотили бы еще столько же. И это все без redis, mongodb, jQuery, node.js — этого тогда просто не было или было в зачаточной стадии.
Это я к чему. Вам все правильно говорят, либо цена сильно завышена, либо вы очень сильно недооптимизировали что-то.
Лет 12 назад я занимался «хайлоадом». Пять серверов, по 200000 запросов на хост в сутки. Это только те, которые что-то меняли в БД — про статику и селекты сейчас не говорим. Сервера были средненькие и по ощущениям проглотили бы еще столько же. И это все без redis, mongodb, jQuery, node.js — этого тогда просто не было или было в зачаточной стадии.
Это я к чему. Вам все правильно говорят, либо цена сильно завышена, либо вы очень сильно недооптимизировали что-то.
20тыс — это кол-во запросов на запись.
Я о том и говорю, что даже учитывая всю «нагрузку» в сутки на базу — это просто смехотворные данные для highload и подобной архитектуры. Возможно так же вопрос не в «недооптимизации» а в избыточной архитектуре. Как говорит автор, под БД используется 3 толстых инстанты на тарифе A7 (если не знакомы, то это: x8 core, 56ggb RAM) — под такую нагрузку в сутки это выглядит ужасающе — я просто ума не приложу зачем такие мощности для столь малой базы данных (по меркам highload). Выглядит так, будто обслуживание этой сложной архитектуры пожирает ресурсов больше, чем создают клиенты вашего сервиса.
Или в azure столь некачественные «ноды» (vps-ки) либо же у автора столь некачественная настройка всего этого зоопарка…
Или в azure столь некачественные «ноды» (vps-ки) либо же у автора столь некачественная настройка всего этого зоопарка…
Сорри, что ввёл в заблуждение по поводу кол-ва A7 и БД.
A7 у нас только один. Такой размер вынужденный из-за размера базы. Общий размер БД сейчас наверное уже >60Gb, а шаг доступной памяти в инстансах 14-28-52. Два других инстанса под БД на A5 и A3 соответственно. CPU нагрузка на них сейчас ~5-7%. Очевидно что это с явным запасом.
Но замечу, что даже если сразу размазывать данные равномерно и постепенно, то по себестоимости будет это равноценно, например, 1xA7 = 2xA6 = 4xA5 и т.д.
Про ресурсы, которые тратятся на обслуживание не понял, уточните пожалуйста.
A7 у нас только один. Такой размер вынужденный из-за размера базы. Общий размер БД сейчас наверное уже >60Gb, а шаг доступной памяти в инстансах 14-28-52. Два других инстанса под БД на A5 и A3 соответственно. CPU нагрузка на них сейчас ~5-7%. Очевидно что это с явным запасом.
Но замечу, что даже если сразу размазывать данные равномерно и постепенно, то по себестоимости будет это равноценно, например, 1xA7 = 2xA6 = 4xA5 и т.д.
Про ресурсы, которые тратятся на обслуживание не понял, уточните пожалуйста.
Не перепутали, всё верно. И да, стоит признать, что некоторые ресурсы могут использоваться не на все 100%, об этом чуть ниже. Но я нигде не говорил, что узкое место в проекте — это БД и что упираемся мы именно в неё? Почему вдруг только это обсуждается в данном случае? Да и примеры о кол-ве запросов на хост хотелось бы видеть с учётом некоторых дополнительных данных: хотя бы общий размер БД и примерная стоимость такого решения (с учётом всех издержек). =\
Хинт: Все проблемы, которые возникали с БД были связаны только с тем, что размер базы переставал помещаться в память, а так как диски очень медленные для подобного рода задач, то приходилось вертикально масштабировать инстанс, чтобы решать эту проблему.
Чтобы не быть голословным вот стоимость Azure VM (https://azure.microsoft.com/en-us/pricing/details/virtual-machines/#Linux) в пересчёте на текущую архитектуру проекта (без учёта стоимости трафика ~15-20 тыс. руб. и стоимость использования хранилищ ~2-5 тыс. руб.):
a7 — 46.5 тыс. руб.
a5 — 11.6 тыс. руб
a3x4 — 44,8 тыс. руб
a2x5 — 28 тыс. руб
Средняя загрузка CPU от 5 до 60%
PS: Да согласен, что можно сэкономить довольно приличную сумму (думаю до 20 тыс. рублей), если перевести инстансы на D-серию, но они появились уже после того как проект был развёрнут и почему-то когда смотрел цены (в своё время!) — они были дороже A-серии. Как только дойдут руки до оптимизации инфраструктуры, обязательно подробно изучу этот момент.
Хинт: Все проблемы, которые возникали с БД были связаны только с тем, что размер базы переставал помещаться в память, а так как диски очень медленные для подобного рода задач, то приходилось вертикально масштабировать инстанс, чтобы решать эту проблему.
Чтобы не быть голословным вот стоимость Azure VM (https://azure.microsoft.com/en-us/pricing/details/virtual-machines/#Linux) в пересчёте на текущую архитектуру проекта (без учёта стоимости трафика ~15-20 тыс. руб. и стоимость использования хранилищ ~2-5 тыс. руб.):
a7 — 46.5 тыс. руб.
a5 — 11.6 тыс. руб
a3x4 — 44,8 тыс. руб
a2x5 — 28 тыс. руб
Средняя загрузка CPU от 5 до 60%
PS: Да согласен, что можно сэкономить довольно приличную сумму (думаю до 20 тыс. рублей), если перевести инстансы на D-серию, но они появились уже после того как проект был развёрнут и почему-то когда смотрел цены (в своё время!) — они были дороже A-серии. Как только дойдут руки до оптимизации инфраструктуры, обязательно подробно изучу этот момент.
Поймите меня правильно. Проект крутой и никто с этим не спорит.
По деньгам — аренда серверов обходилась в сумму порядка $1000. По ощущениям, учитывая разницу курса и инфляцию, эта цифра сопоставима с вашими затратами.
А по перфомансу и железу… Были у нас, кажись, четвертые пни и один селерон. Памяти точно уже не помню сколько, но не более гига. База более 60 Гб, размазывали по хостам. На каждый запрос апдейты в базу, вообще говоря, не сильно тривиальные были для такого потока. Не думаю, что проще добавления комментов. Потом удалось неплохо оптимизировать. CPU использовались тоже где-то в районе 50-60%
Конечно, в лоб сравнивать технологии/издержки и производительность в запросах в секунду — некорректно. Но все же, общее представление дает. В общем, странно как-то.
Скажем так, я ни на что не претендую — давно уже не в этой сфере, но я сильно удивлен разницы в несколько порядков.
По деньгам — аренда серверов обходилась в сумму порядка $1000. По ощущениям, учитывая разницу курса и инфляцию, эта цифра сопоставима с вашими затратами.
А по перфомансу и железу… Были у нас, кажись, четвертые пни и один селерон. Памяти точно уже не помню сколько, но не более гига. База более 60 Гб, размазывали по хостам. На каждый запрос апдейты в базу, вообще говоря, не сильно тривиальные были для такого потока. Не думаю, что проще добавления комментов. Потом удалось неплохо оптимизировать. CPU использовались тоже где-то в районе 50-60%
Конечно, в лоб сравнивать технологии/издержки и производительность в запросах в секунду — некорректно. Но все же, общее представление дает. В общем, странно как-то.
Скажем так, я ни на что не претендую — давно уже не в этой сфере, но я сильно удивлен разницы в несколько порядков.
Спасибо за понимание. Вы всё верно говорите. Да, действительно колокейшен будет выходить дешевле, но в итоге на его полноценное обслуживание потребуется отдельный человек со своей стоимостью и итоговые цены на поддержку инфраструктуры окажутся сопоставимыми. Например текущую конфигурацию можно собрать и за половину цены, но тогда ещё же должен появиться человек, который всё это правильно соберёт, настроит и будет поддерживать.
По поводу возникающего недопонимания касательно стоимости и запросов (sic!): статистика запросов, которая приведена в статье, — это не общая статистика проекта, а кол-во прироста новых данных в сутки. Видимо это не так очевидно оказалось?
По поводу возникающего недопонимания касательно стоимости и запросов (sic!): статистика запросов, которая приведена в статье, — это не общая статистика проекта, а кол-во прироста новых данных в сутки. Видимо это не так очевидно оказалось?
Нет, я вас правильно понял. В нашем случае это нельзя назвать напрямую скоростью прироста данных — ибо параллельно шел процесс ротейта/архивации — иначе бы в стораж не влезли, но каждый запрос осуществлял запись в БД и даже подсчет некоторой минимальной статистики (апдейтами по БД). Так что по вычислительной сложности сопоставлять эти данные можно — ну, хотя бы порядок цифр.
Про плюсы/минусы dedicated server vs. cloud разумеется, разговора нет. Кроме того, расходы сопоставимы в нашем и вашем случаях. Но не стоит забывать, что это было достаточно давно
Про плюсы/минусы dedicated server vs. cloud разумеется, разговора нет. Кроме того, расходы сопоставимы в нашем и вашем случаях. Но не стоит забывать, что это было достаточно давно
Удвою. Есть один сайт, который в пике 300rps получает, так ему шести ядер и двадцати гигов памяти хватает, из которых процентов 80 потребляет MySQL.
А какая сервиса монетизация?
Из чего складывается 140 тыс. в месяц? Какие машины используете? Сколько?
Из чего складывается 140 тыс. в месяц? Какие машины используете? Сколько?
В настоящий момент используется грант BizSpark.
Что касается модели монетизации, то активно работаем в этом направлении. В настоящий момент есть:
— контекст (~75%)
— меценатские взносы (~20%)
— платные услуги (~5%)
Про конфигурацию сказал чуть выше в комментарии. Если нужно детальнее, то могу ответить в личке.
Что касается модели монетизации, то активно работаем в этом направлении. В настоящий момент есть:
— контекст (~75%)
— меценатские взносы (~20%)
— платные услуги (~5%)
Про конфигурацию сказал чуть выше в комментарии. Если нужно детальнее, то могу ответить в личке.
когда грант закончится, скорее всего, вам придется переезжать, ажура и была не дешевая, а с баксом и их 2ггц cpu пришлось уходить. Сервис вместо обработки файла в 5-9 секунд на VPS работал там все 20-30. Понятно, что инфраструктура удобная — но капец она дорого выходит, просто капец. Эти 99.99% стабильности вместо 98% как бы не таких крутых контор стоят слишком дорого.
Надеюсь что не придётся. В целом сейчас добываемых денег почти хватит, как раз чтобы там остаться (за вычетом некоторых фич сервиса) + мы активно работаем в этом направлении.
Про медленные диски согласен — говорил об этом, — но в целом это решаемо.
В нашем случае ещё стоит помнить о том, что с Azure сейчас мы не тратимся на специалиста по обслуживанию и поддержке инфраструктуры (увы у нас не хватает собственных компетенций в этом). А если переезжать, то такой человек по-любому понадобится, а это получатся сопоставимые средства.
Про медленные диски согласен — говорил об этом, — но в целом это решаемо.
В нашем случае ещё стоит помнить о том, что с Azure сейчас мы не тратимся на специалиста по обслуживанию и поддержке инфраструктуры (увы у нас не хватает собственных компетенций в этом). А если переезжать, то такой человек по-любому понадобится, а это получатся сопоставимые средства.
В Azure цены в рублях, в отличии от некоторых других публичных облаков. Поэтому на скачки доллара с Azure можно внимания не обращать. Корректировка цен происходит как вверх так и вниз, на моей памяти один-два раза в год.
Скажите, а аренда аппаратного сервера на паре Xeon v3 + 128 Гб ОЗУ + несколько SSD-дисков, тысяч за 30-40 в месяц — неужели бы такой мощности не хватило бы, чтобы выдержать "~2.5 тыс даров и ~1.5 тыс благодарностей, ~20 тыс. комментариев, ~40 тыс. уведомлений и ~4.5 тыс. файлов"? Причем на такой машине отлично можно поднять свою виртуализацию (Hyper-V, KVM — да к чему душа лежит!), нарезать машинок и пускай оно работает.
На 100 тыс. в месяц дешевле названного вами месячного ценника.
На 100 тыс. в месяц дешевле названного вами месячного ценника.
ажура адово стоит + бакс сыграл свое, из за этого и ушли с нее. Но у нее есть плюшки по типу защита от DDOS по умолчанию. В любом случае она крайне дорога, те 99.99% стабильности по мне не стоят переплаты в два три раза в мес.
Так все облака стоят адово. Не в последнюю очередь от того, что программист стоит дороже сервера, поэтому никто не будет оплачивать неделю программера, чтобы на 3% ускорить работу и на 40% уменьшить нагрузку на сервер при выводе списка товаров, скажем. Когда сервер «твой» (аренда, владение), то тебя это не задевает (почти — мало кто точно отслеживает потребляемую электроэнергию в смысле выставления счета). А когда оно живет в облаке, то за каждый неоптимальный чих ты платишь, и это требует понимания, что и за что. При 140К руб. за хостинг(!) можно нанять одного-двух толковых ребят разбираться с косяками кода, чтобы в конце работ получить 100К :) Правда, тот же сайт, отрендеренный в html, наверняка даст 10К ;)) А можно, правда, взять машину железную, и быть себе хозяином.
Ключевое слово тут — «грант». Но авторам сайта с нагрузкой в «2.5 даров» можно, наверное, и задуматься, уж очень удельная затрата на один «дар» высоковата. Highload-ом при этом вроде как пахнуть не должно, это же не миллионы страниц в день.
Правда, если авторы научатся на донейтах и рекламе заработать хотя бы 140К в мес, то переход на выделенный сервер им покажется просто подарком )))
Ключевое слово тут — «грант». Но авторам сайта с нагрузкой в «2.5 даров» можно, наверное, и задуматься, уж очень удельная затрата на один «дар» высоковата. Highload-ом при этом вроде как пахнуть не должно, это же не миллионы страниц в день.
Правда, если авторы научатся на донейтах и рекламе заработать хотя бы 140К в мес, то переход на выделенный сервер им покажется просто подарком )))
В реальности все ровно наоброт, после скачков цен на Azure перешло множество клиентов с Amazon. Просто потому, что в Azure ценник рублевый.
Если рассчитывать коллокейшн с необходимым железом, то получается (рассчитывал в своё время) примерно 1/3 стоимости — это если брать всё впритык, если с запасом — уже ~1/2. И это только само железо, а ещё его настройка и конфигурация потребуют специалиста, которого у нас просто нет, а собственных знаний в этом деле, увы, недостаточно.
Это конечно вопрос холиварный: collocation vs cloud. =) Правда издержки на самом деле распределяются по разному. В одной песочнице они идут на специалиста(ов), который всё это поднимает, настраивает, обслуживает. А в другой на стоимость услуги. В итоге оно выходит примерно эквивалентно.
Что касается предложенной конфигурации, то сказать сходу не могу (в виртуализации не силён): тут наверное надо смотреть и сравнивать конкретные показатели. Что-то мне подсказывает, что может не хватить.
Это конечно вопрос холиварный: collocation vs cloud. =) Правда издержки на самом деле распределяются по разному. В одной песочнице они идут на специалиста(ов), который всё это поднимает, настраивает, обслуживает. А в другой на стоимость услуги. В итоге оно выходит примерно эквивалентно.
Что касается предложенной конфигурации, то сказать сходу не могу (в виртуализации не силён): тут наверное надо смотреть и сравнивать конкретные показатели. Что-то мне подсказывает, что может не хватить.
Как-то из "~2.5 тыс даров и ~1.5 тыс благодарностей, ~20 тыс. комментариев, ~40 тыс. уведомлений и ~4.5 тыс. файлов", то есть всего из 70 000 вызовов, не складывается картина высоконагруженого сервиса. В сутках 86 400 секунд, получается, что у вас меньше одного вызова в секунду. Полагаю, что вы чего-то не договариваете, например, у вас в сотни раз больше простых просмотров страниц пользователями, не приводящих ни к одному из описаных вами действий (комментирование\дарение\etc..), но создающих нагрузку.
В любом случае, имеет смысл обратится для начала за консультацией к специалисту, часто можно простым тюнингом конфига значительно улучшить производительность и сэкономить на HW.
Успехов вам и вашему проекту!
В любом случае, имеет смысл обратится для начала за консультацией к специалисту, часто можно простым тюнингом конфига значительно улучшить производительность и сэкономить на HW.
Успехов вам и вашему проекту!
Повторюсь, статистика приведённая в статье — это примерная статистика ежедневного добавления записей в базу, а не суммарная нагрузка. Когда отвечал в этом интервью думал какие дать показатели для иллюстрации и решил для наглядности ограничиться дельтой прироста данных в сутки (к тому же это даёт ещё и представление об активности самого сервиса).
6 лет назад работал над одним проектом, простой тематический сайт о телефонах и их контенте. В сутки было около 3М запросов (это без запросов на отдачу статики), если я ничего не путаю, запросы только на PHP, БД был мускуль, пока запросов было до 1М, висел на том же тазике, но после решил вынести на отдельный, для увеличения стабильности. В итоге 3М запросов в сутки и всего 2 сервера! И это было более 6 лет назад! 6 лет как я там уже не работаю…
Извините, но озвученные Вами суммы и нагрузки просто смешные! Нам все обходилось порядка 1.2-1.5 К зелени…
Извините, но озвученные Вами суммы и нагрузки просто смешные! Нам все обходилось порядка 1.2-1.5 К зелени…
У меня возникает цепочка очень глупых вопросов — а нормализация данных производилась? шли ли когда-то на осознанную денормализацию? (и совсем глупый) А индексы точно правильно расставлены? Потому что размер базы данных в 60 гигабайт выглядит не сильно то и большим. Для достаточно быстрой работы достаточно, чтобы все индексы помещались в память и немного из активно используемых данных.
Можно как-то увидеть схему данных? Можно ли включить в БД логирование медленных и неоптимальных запросов?
Жуткие тормоза можно ожидать, если происходит полное сканирование огромной таблицы в результате поискового запроса. Сталкивался с тем, что в mysql запрос видa field LIKE "%test%" выполняется с игнорированием индексов. в то время как field LIKE «test%» отрабатывал почти мгновенно.
К счастью, в MySQL начиная с 5.6 появился полнотекстовый поиск и в InnoDB, что уже позволяет выполнять тяжелые поисковые запросы по тексту быстро и дополнительными плюшками.
Опять же — в архитектуре упомянут SPHINX, который чрезвычайно быстр в такой ситуации, если его использовать…
Я понимаю, что желание запрятать всё в оперативную память следует из упомянутого минуса
— Системный диск VM крайне медленный и использовать его поэтому нужно осторожно или не использовать вовсе.
Понятно, что там конкурентная среда и одним жестким диском разом могут пользоваться многие, но насколько же он медленный? Скорость 3.5" флопика? CD? IDE HDD 4400 RPM?
Если конкретно линуксовый инстанс работает медленно с жестким диском, почему сервер БД не поднять на Win? Почему не настроить master-slave реплику, причем рабочая реплика как раз будет на временном быстром диске?
Можно как-то увидеть схему данных? Можно ли включить в БД логирование медленных и неоптимальных запросов?
Жуткие тормоза можно ожидать, если происходит полное сканирование огромной таблицы в результате поискового запроса. Сталкивался с тем, что в mysql запрос видa field LIKE "%test%" выполняется с игнорированием индексов. в то время как field LIKE «test%» отрабатывал почти мгновенно.
К счастью, в MySQL начиная с 5.6 появился полнотекстовый поиск и в InnoDB, что уже позволяет выполнять тяжелые поисковые запросы по тексту быстро и дополнительными плюшками.
Опять же — в архитектуре упомянут SPHINX, который чрезвычайно быстр в такой ситуации, если его использовать…
Я понимаю, что желание запрятать всё в оперативную память следует из упомянутого минуса
— Системный диск VM крайне медленный и использовать его поэтому нужно осторожно или не использовать вовсе.
Понятно, что там конкурентная среда и одним жестким диском разом могут пользоваться многие, но насколько же он медленный? Скорость 3.5" флопика? CD? IDE HDD 4400 RPM?
Если конкретно линуксовый инстанс работает медленно с жестким диском, почему сервер БД не поднять на Win? Почему не настроить master-slave реплику, причем рабочая реплика как раз будет на временном быстром диске?
Буду отвечать по порядку.
0. Не очень ясно почему многих волнуют вопросы связанные именно с БД, т.к. нигде не говорится о том, что у нас это узкое место. Упираемся мы в настоящее другом месте, а именно забивание app-слоя и media-хранилища по CPU. Вопрос на который я пока, к сожалению, не могу дать ясного ответа. Итак.
1. Всегда начинаем с нормальной формы, а затем исходя из необходимости делаем денормализацию.
1. Индексы стараемся делать своевременно и по запросам. «Старые» таблицы уже точно полностью покрыты необходимыми индексами. Проверяем по explain и не стесняемся использовать force index.
2. Проблема размера заключается в том, что архивные данные (более полугода) также являются актуальными и могут быть использованы наравне с горячими (до полугода). Все проблемы, с которыми мы сталкивались касательно БД заключались именно в том, что она переставала помещаться в памяти и тогда начинали случаться дикие тормоза, особенно в те моменты, когда кто-то из пользователей решает внимательно полазить по архивам или профилям.
3. Схему данных выдать не смогу, долго рисовать. Могу сказать, что у нас сейчас используется более 100 таблиц. Практически не пользуемся left/inner join. Что касается логирования запросов, то есть возможность включить «дебаг-режим» для каждой страницы и увидеть лог её «сборки» (включая выполняемые на странице запросы, время их исполнения и общее время генерации). В настоящее момент среднее время генерации страниц 0.1-0.3 с. Время sql запросов исчисляется тысячными долями (исключение составляют фоновые неоптимизированные статистические методы). Для наиболее частых выборках реализовано кеширование.
4. Запросов с полным сканированием данных почти нет. Стараемся не допускать такие моменты или терпим до тех пор пока в таблице мало данных. Для полнотекстового поиска везде в проекте используется sphinx.
5. Расскажу как было. Когда переехали и всё настроили, протестировали — открылись. И тут же повисли. Начали разбираться в чём дело и увидели, что iostat показал загрузку системного диска в 100%. Притом, что нагрузка была такая же как и раньше или даже меньше, а «железо» вроде даже с небольшим запасом. Начали исследовать и получили следующие данные: системный диск ~3 Мб/c, «временный» ~300-400 Мб/c, подключаемый blob-storage ~50-100 Мб/c. Оговорюсь сразу, что это замеры 2-3 летней давности, сейчас может быть что-то поменялось. Когда разнесли всё на «временный» и подключаемый blob-storage — всё начало работать.
6. Не факт что БД на Win будет работать резвее, потому как вроде как системный и временные диски там используются те же. Плюс поддержка, настройка под продакшн: никогда с этим не сталкивался, только в локальных dev средах.
7. Делать репликацию на временный диск нецелесообразно, так как велика вероятность не восстановить slave после ребута/ресайза инстанса. Но как решение для экономии допустимо, если научиться slave плодить как кроликов с актуальными данными. Правда в таком случае всё равно, мне кажется, экономия скорее будет касаться blob-хранилища, а не размера инстанса.
0. Не очень ясно почему многих волнуют вопросы связанные именно с БД, т.к. нигде не говорится о том, что у нас это узкое место. Упираемся мы в настоящее другом месте, а именно забивание app-слоя и media-хранилища по CPU. Вопрос на который я пока, к сожалению, не могу дать ясного ответа. Итак.
1. Всегда начинаем с нормальной формы, а затем исходя из необходимости делаем денормализацию.
1. Индексы стараемся делать своевременно и по запросам. «Старые» таблицы уже точно полностью покрыты необходимыми индексами. Проверяем по explain и не стесняемся использовать force index.
2. Проблема размера заключается в том, что архивные данные (более полугода) также являются актуальными и могут быть использованы наравне с горячими (до полугода). Все проблемы, с которыми мы сталкивались касательно БД заключались именно в том, что она переставала помещаться в памяти и тогда начинали случаться дикие тормоза, особенно в те моменты, когда кто-то из пользователей решает внимательно полазить по архивам или профилям.
3. Схему данных выдать не смогу, долго рисовать. Могу сказать, что у нас сейчас используется более 100 таблиц. Практически не пользуемся left/inner join. Что касается логирования запросов, то есть возможность включить «дебаг-режим» для каждой страницы и увидеть лог её «сборки» (включая выполняемые на странице запросы, время их исполнения и общее время генерации). В настоящее момент среднее время генерации страниц 0.1-0.3 с. Время sql запросов исчисляется тысячными долями (исключение составляют фоновые неоптимизированные статистические методы). Для наиболее частых выборках реализовано кеширование.
4. Запросов с полным сканированием данных почти нет. Стараемся не допускать такие моменты или терпим до тех пор пока в таблице мало данных. Для полнотекстового поиска везде в проекте используется sphinx.
5. Расскажу как было. Когда переехали и всё настроили, протестировали — открылись. И тут же повисли. Начали разбираться в чём дело и увидели, что iostat показал загрузку системного диска в 100%. Притом, что нагрузка была такая же как и раньше или даже меньше, а «железо» вроде даже с небольшим запасом. Начали исследовать и получили следующие данные: системный диск ~3 Мб/c, «временный» ~300-400 Мб/c, подключаемый blob-storage ~50-100 Мб/c. Оговорюсь сразу, что это замеры 2-3 летней давности, сейчас может быть что-то поменялось. Когда разнесли всё на «временный» и подключаемый blob-storage — всё начало работать.
6. Не факт что БД на Win будет работать резвее, потому как вроде как системный и временные диски там используются те же. Плюс поддержка, настройка под продакшн: никогда с этим не сталкивался, только в локальных dev средах.
7. Делать репликацию на временный диск нецелесообразно, так как велика вероятность не восстановить slave после ребута/ресайза инстанса. Но как решение для экономии допустимо, если научиться slave плодить как кроликов с актуальными данными. Правда в таком случае всё равно, мне кажется, экономия скорее будет касаться blob-хранилища, а не размера инстанса.
Sign up to leave a comment.
Дарудар — облако в дар от Microsoft