![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
avvaЕсли написанный мной memcached будет использовать Слэшдот (search for 'memcached' inside that page) — вот это будет номер :-)
avvaЕсли написанный мной memcached будет использовать Слэшдот (search for 'memcached' inside that page) — вот это будет номер :-)
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2003-06-14 02:01 pm (UTC)no subject
no subject
Date: 2003-06-15 01:33 am (UTC)no subject
Date: 2003-06-15 01:48 am (UTC)В MySQL отсутствует куча лишней дряни которая замедляет кверии в десятки раз но при этом никогда не используется. Кроме того она прозрачна и в ней мало залепух.
Re:
Date: 2003-06-15 02:06 am (UTC)Волга впадает в Каспийское озеро
день смерти Оракла видится мне чрезвычайно далёким
смерть -- неизбежна
у мыскля есть масса хороших сторон
Россия -- наше отечество
и вообще, Вы когда к границе подлетали, зелёную рожу с высунутым языком видали?
Re:
Date: 2003-06-15 02:17 am (UTC)Да, а зеленую рожу не видел. Каюсь!
no subject
Date: 2003-06-15 05:51 pm (UTC)no subject
Date: 2003-06-15 05:50 pm (UTC)no subject
no subject
Date: 2003-06-14 04:13 pm (UTC)Можно вопрос?
Date: 2003-06-14 10:58 pm (UTC)Задача, по сути, является поиском значения по индексированному ключу. Я не знаю цифр по MySQL, но и MSSQL и ORACLE могут исполнять в 1.5 раза большее количество подобных запросов на машине имеющей всего 4Gb памяти. В лоб, не используя каких-то специальных подходов.
Я не знаю -- может быть нагрузка на memcached значительно выше, чем я оценил, именно поэтому я как-то спрашивал вас о количественной оценке производительности memcached. Собственно вопрос такой: по вашему мнению, начиная с какого объема запросов использование memcached является эффективным?
Re: Можно вопрос?
Date: 2003-06-15 06:40 am (UTC)Secundo: memcached как решение стоит 150 долларов (просто ставим в уже работающую машину дополнительный гигабайт оперативки) и порядка двух часов на всю процедуру внедрения — сборка, запуск, начали работать. Масштабирование его на два, три и более демонов — еще 150 долларов и полчаса на осознание, как правильно раскидывать по ним запросы.
Теперь MSSQL или Oracle. Цена внедрения - порядка $15 000 - выделенный сервер с минимум 2 CPU, быстрым дисковым массивом и 4 гигами оперативки, плюс $5000 per CPU за ?MS SQL Stantard Edition (на Оракл я цен не знаю, вряд ли сильно дешевле), и в самом оптимистичном случае ещё порядка недели на инсталляцию и оптимизацию. Цена масштабирования - скорее всего того же порядка в деньгах и пара дней времени, правда происходит это прозрачно для уровня бизнес-логики.
Вот, собственно, и вся любовь. На вопрос "почему никто не додумался до этого раньше", который я сам себе задаю, ответ видимо несложный: уровень цен на память, а также на архитектурные и программные решения, позволяющие эту память линейно адресовать, упал до неприличного уровня в течение буквально последнего года.
Re: Можно вопрос?
Date: 2003-06-16 03:36 am (UTC)Не подвергая сомнению Вашу точку зрения в целом, я хотел бы просто любопытства ради прояснить один момент.
Secundo: memcached как решение стоит 150 долларов (просто ставим в уже работающую машину дополнительный гигабайт оперативки) и порядка двух часов на всю процедуру внедрения — сборка, запуск, начали работать.
Адаптация существующих приложений (см. "Porting the Application"), очевидно, займёт несколько более двух часов. Вы не включаете адаптацию в понятие "внедрение" или я чего-то не понимаю?
Re: Можно вопрос?
Date: 2003-06-16 03:59 am (UTC)Вот лично для меня это глубоко неочевидно. Я специально посмотрел еще вчера все места в коде ЖЖ, где встречается обращение к memcache. Таковых мест наскреблось с два десятка в девяти файлах. Всей работы, при условии понимания механизма, как раз на искомые два часа.
Re: Можно вопрос?
Date: 2003-06-16 04:01 am (UTC)Re: Можно вопрос?
Date: 2003-06-16 04:08 am (UTC)Кстати, Анатолий, а каковы шансы у вашего демона быть успешно собранным под CygWin с mingw32?
Re: Можно вопрос?
Date: 2003-06-16 04:17 am (UTC)В самом memcached единственное, что я могу представить в качестве проблемы - это вызов daemon() при запуске с ключом -d; его может не быть в mingw32, но его можно просто убрать или переписать с помощью fork().
В общем, я бы сказал, минут на 20 работы проверить, собирается ли сразу, и на час-два работы поправить, если собирается не сразу. Но следует учитывать, что: 1) poll() под Win32 наверняка будет не очень эффективным при большом количестве подключений (больше 300, скажем); 2) если под Win32 у mingw32 особенно тупой malloc(), то это может сказаться на перформансе.
Мечтательно
Date: 2003-06-16 04:32 am (UTC)Re: Можно вопрос?
Date: 2003-06-15 05:40 pm (UTC)Нет, сами запросы SQL обычно бывают куда сложнее.
Знаете, мне трудно оценить нагрузку, потому что я в основном занимаюсь написанием и отладкой, а не запуском и мониторингом. Сейчас я прикинул приблизительно по выводу на внутреннюю (сделанную Брадом только для админов) страницу статистики memcache, и выходит, что в данный момент бегут 10 процессов и каждый из них принимает на себя примерно 660 запросов в секунду, из них примерно 580 чтение и 80 - запись. Всего получается несколько больше, чем 6.5 тысяч запросов в секунду -- но сейчас не пиковые часы, а главное, воскресенье. В понедельник траффик ЖЖ возрастает по сравнению с воскресеньем в 2-3 раза (не помню точно, во сколько).
Более того, я не специалист по БД совершенно. До работы в ЖЖ я вообще в жизни дела с SQL не имел! Переход на другие БД вместо MySQL для ЖЖ не стоит не повестке дня, по нескольким причинам сразу. Факт, что работая с тем, что есть, memcached очень эффективно снизил нагрузку. Нужен ли memcached проекту, который работает с "настоящим"/"крутым"/как-его-там-ни-назови сервером БД? На мой личный взгляд, есть веские причины, позволяющие считать, что и в таком случае memcached может очень пригодиться. Но я в этом случае не считаю себя экспертом и не готов эти аргументы или наброски аргументов отстаивать.
Если Вам действительно интересна и близка эта тема, советую написать письмо Брэду, он сможет ответить на Ваши вопросы (как по поводу статистики, так и по поводу целесообразности использования memcached с другими БД) гораздо лучше меня -- и он почти всегда отвечает на грамотно и разумно написанные письма.
Re: Можно вопрос?
Date: 2003-06-16 08:41 am (UTC)Мне было интересно насколько Ваш подход эффективен. Похоже, что очень эффективен.
На мой личный взгляд, есть веские причины, позволяющие считать, что и в таком случае memcached может очень пригодиться.
Ну так я Ваш личный взгляд и спрашивал. Вы же автор, Вас и спросил. А мнение Брэда по этому поводу я уже читал (http://www.livejournal.com/community/lj_maintenance/60984.html) в lj_maintenance.
Re: Можно вопрос?
Date: 2003-06-16 01:18 pm (UTC)no subject
Date: 2003-06-15 09:56 am (UTC)Re:
Date: 2003-06-15 01:55 pm (UTC)no subject
(далее - голосом Дроздова)
Кроме программистов в непосредственной близости от баз данных обитают такие виды млекопитающих, как системные аналитики, алгористмисты и, naturally, администраторы-баз-данных, они же ди-би-эй, ну и, конечно, писатели. Технические. Technical writers то есть :)
no subject
Date: 2003-06-16 02:22 am (UTC)2) в предыдущем проекте один мой коллега предложил в точности такую идею -- 'caching factory', слой поверх БД. Там ещё был 'cache prefetch': если какой-то объект часто требуется (высоко в LRU-списке), а у него время жизни истекает, то он мог быть без внешнего воздействия "освежён" из БД низкоприоритетной ниткой. Всё это вместе повысило производительность в разы. БД была Oracle, кстати, и настроена вполне неплохо :-)
все же мне это немного странно
Date: 2003-06-16 08:45 am (UTC)Другое дело что в MySQL нет то ли всего, то ли части (я не спец) из описанного, так что вроде как раз был прав
Разве что, ни в одной базе, насколько мне известно, нет никаких cache control директив; т. е. все эти кеши работают как черные ящики сами по себе, что иногда мешает (особенно при работе с кешем тьюплов, кеш запросов еще можно как-то оттьюнить меняя запись запроса).
Еще вспоминается главное ноу-хау Альтависты, Very Large In-Memory Index или как-то так, времен когда трава была зеленей, поиск медленный а память дорогая.
Re: все же мне это немного странно
Date: 2003-06-16 09:08 am (UTC)Т. е., imho, memcached решает (также и) проблему кэширования сразу нужного набора данных, в отличие от кэширования мелких кусочков с оверхедом на сборку из них целого.
Насчёт альтависты -- вон гугль вообще весь в памяти и ничего :-)
я, признаюсь,
Date: 2003-06-16 12:10 pm (UTC)я сравнивал этот вариант с (временным) хранением аналога таблички соответствий (которая должна быть внутри memcached) непосредственно в базе. т. е. в базе было б написано -- уникальный ключ в понятиях логики приложения равен такому-то набору таких-то разношерстных записей (адресованных сразу по уникальным индексам). вкупе с поднятым кешем тьюплов это, на мой взгляд, дало бы примерно тот же эффект что и memcached.
некоторую часть, предположительно имеющуюся в memcached -- менеджмент самой таблички уникальных ключей и соответствующих им записей -- все равно пришлось бы написать; но не нужно было б писать логику кеширования, она пришла бы с кешированием тьюплов в базе.
вполне возможно, я что-то упускаю -- я очень поверхностно знаком со всеми сторонами предмета, и моя конструкция представляется мне шаткой. хотелось бы как раз где именно она шатается.
Re: я, признаюсь,
Date: 2003-06-16 04:57 pm (UTC)Вы же высказываетесь в том духе, что решение за несколько десятков тысяч долларов, буде поднято и должным образом настроено, возможно, смогло бы решить эту проблему, а возможно и не смогло бы — надо смотреть саму задачу вживую. Как-то в таком свете меня много больше устраивает готовое решение Анатолия. :)
Сергей,
Date: 2003-06-17 04:14 am (UTC)Мне было интересно это решение положить в общую картину (как и вам, только с другого края). Я специально написал ответ на коммент
no subject
Date: 2003-06-16 05:11 pm (UTC)Впрочем, это уже будет не ЖЖ.
Re:
Date: 2003-06-16 05:16 pm (UTC)Вот именно. А что будет с ЖЖ -- будем посмотреть.
no subject
Date: 2009-06-27 07:57 pm (UTC)Ну что же, Анатолий, как вы считаете - тот самый "момент номера" пришел? =)
Спасибо вам за мемкэш ;-)
Проектирование систем технической безопасности
Date: 2011-07-02 09:39 am (UTC)