рабочее

[avva]

Если написанный мной memcached будет использовать Слэшдот (search for 'memcached' inside that page) — вот это будет номер :-)

Comments

[pendelschwanz.livejournal.com]

Объясни теперь старому глупому еврею, эта меморная каша - она что, хранит в себе предыдущии кверии к Моей Эскуэлии? В чем от нея кайф?

[ex-ilyavinar899.livejournal.com]

Что такое danga.com?

[cmm.livejournal.com]

в том, что героически залепляет очередное отличие MySQL от серьёзной базы данных.

[avva.livejournal.com]

Just a nonsense word Brad picked up long time ago when he needed to think of a name for a company. This was before LiveJournal. There's LiveJournal.com Inc. now as well.

Можно вопрос?

[s1m.livejournal.com]

На сайте вы пишите: "...a site which was already doing 20 million+ dynamic page views per day...". Если оценить количество запросов к memcached в 10 запросов на один просмотр страницы, тоэто получится 200 миллионов запросов в день. Очевидно, что нагрузка распределяется не равномерно по времени и основной объем запросов (судя по статистики использования LJ) приходится на световой день США. Но даже если распределить 200 миллионов запросов на 12 часов, то должно получиться около 4500 запросов в секунду.

Задача, по сути, является поиском значения по индексированному ключу. Я не знаю цифр по MySQL, но и MSSQL и ORACLE могут исполнять в 1.5 раза большее количество подобных запросов на машине имеющей всего 4Gb памяти. В лоб, не используя каких-то специальных подходов.

Я не знаю -- может быть нагрузка на memcached значительно выше, чем я оценил, именно поэтому я как-то спрашивал вас о количественной оценке производительности memcached. Собственно вопрос такой: по вашему мнению, начиная с какого объема запросов использование memcached является эффективным?

[stas]

У MYSQL, кстати, есть query cache. Но довольно тупой во-первых, и не помогает сильно во-вторых, т.к. не предотвращает трату времени на пересылку запроса, получаение результата и его разбор.

[pendelschwanz.livejournal.com]

Doch, MySQL как раз и есть сурьезная базаданных, а что до нее было - ОКА, КАМА, АДАБАС, Оракул, ДБ2, Мокросовтскулсервер - халтурные поделки. Недаром фирма SAP отказалась от собственных поделок и решила принять платформу MySQL.
В MySQL отсутствует куча лишней дряни которая замедляет кверии в десятки раз но при этом никогда не используется. Кроме того она прозрачна и в ней мало залепух.

Re:

[cmm.livejournal.com]

залепухи бывают и вполне полезные
Волга впадает в Каспийское озеро
день смерти Оракла видится мне чрезвычайно далёким
смерть -- неизбежна
у мыскля есть масса хороших сторон
Россия -- наше отечество

и вообще, Вы когда к границе подлетали, зелёную рожу с высунутым языком видали?

Re:

[pendelschwanz.livejournal.com]

Россия -- ваше отечество!
Да, а зеленую рожу не видел. Каюсь!

Re: Можно вопрос?

[sergeax.livejournal.com]

Primo: 10 запросов на один просмотр страницы — это очень оптимистичная оценка. Основную нагрузку на серверы дает построение friends views, а это в среднем 20 сложных многотабличных запросов (сама запись, текст записи, юзерпик, mood/music, группы френдов, что-то ещё я наверняка забыл) или, соответственно, от 40 до 80 простых запросов к одной таблице (что в случае MySQL предпочтительнее).

Secundo: memcached как решение стоит 150 долларов (просто ставим в уже работающую машину дополнительный гигабайт оперативки) и порядка двух часов на всю процедуру внедрения — сборка, запуск, начали работать. Масштабирование его на два, три и более демонов — еще 150 долларов и полчаса на осознание, как правильно раскидывать по ним запросы.

Теперь MSSQL или Oracle. Цена внедрения - порядка $15 000 - выделенный сервер с минимум 2 CPU, быстрым дисковым массивом и 4 гигами оперативки, плюс $5000 per CPU за ?MS SQL Stantard Edition (на Оракл я цен не знаю, вряд ли сильно дешевле), и в самом оптимистичном случае ещё порядка недели на инсталляцию и оптимизацию. Цена масштабирования - скорее всего того же порядка в деньгах и пара дней времени, правда происходит это прозрачно для уровня бизнес-логики.

Вот, собственно, и вся любовь. На вопрос "почему никто не додумался до этого раньше", который я сам себе задаю, ответ видимо несложный: уровень цен на память, а также на архитектурные и программные решения, позволяющие эту память линейно адресовать, упал до неприличного уровня в течение буквально последнего года.

[whitebear.livejournal.com]

Я вот думаю: почему В ОСНОВНОМ программистам? :) Кому, кроме программистов это еще может быть интересно? :)

Re:

[avva.livejournal.com]

Это пусть они сами -- те, кому интересно -- решают.

Re: Можно вопрос?

[avva.livejournal.com]

Задача, по сути, является поиском значения по индексированному ключу.

Нет, сами запросы SQL обычно бывают куда сложнее.

Знаете, мне трудно оценить нагрузку, потому что я в основном занимаюсь написанием и отладкой, а не запуском и мониторингом. Сейчас я прикинул приблизительно по выводу на внутреннюю (сделанную Брадом только для админов) страницу статистики memcache, и выходит, что в данный момент бегут 10 процессов и каждый из них принимает на себя примерно 660 запросов в секунду, из них примерно 580 чтение и 80 - запись. Всего получается несколько больше, чем 6.5 тысяч запросов в секунду -- но сейчас не пиковые часы, а главное, воскресенье. В понедельник траффик ЖЖ возрастает по сравнению с воскресеньем в 2-3 раза (не помню точно, во сколько).

Более того, я не специалист по БД совершенно. До работы в ЖЖ я вообще в жизни дела с SQL не имел! Переход на другие БД вместо MySQL для ЖЖ не стоит не повестке дня, по нескольким причинам сразу. Факт, что работая с тем, что есть, memcached очень эффективно снизил нагрузку. Нужен ли memcached проекту, который работает с "настоящим"/"крутым"/как-его-там-ни-назови сервером БД? На мой личный взгляд, есть веские причины, позволяющие считать, что и в таком случае memcached может очень пригодиться. Но я в этом случае не считаю себя экспертом и не готов эти аргументы или наброски аргументов отстаивать.
Если Вам действительно интересна и близка эта тема, советую написать письмо Брэду, он сможет ответить на Ваши вопросы (как по поводу статистики, так и по поводу целесообразности использования memcached с другими БД) гораздо лучше меня -- и он почти всегда отвечает на грамотно и разумно написанные письма.

[avva.livejournal.com]

Она скорее хранит их уже обработанные результаты, этих запросов. Если ,например, нужно построить какой-то сложный объект, для которого нужно сделать много разных запросов к базе данных, memcached может хранить уже сам готовый объект в составленном виде, а не каждый запрос в отдельности. По сути дела этот кэш ничего не "знает" про базы данных -- он просто хранит присланные ему куски данных, проиндексированные по ключам, и по ключам же выдаёт обратно. Код ЖЖ, когда он вытягивает что-то нетривиальное из БД, посылает это сразу в этот кэш (а перед попыткой вытягивать из БД спрашивает у кэша, нет ли у него уже).

[avva.livejournal.com]

нифига-нифига.

[nine_k]

1) это было бы круто :-)

2) в предыдущем проекте один мой коллега предложил в точности такую идею -- 'caching factory', слой поверх БД. Там ещё был 'cache prefetch': если какой-то объект часто требуется (высоко в LRU-списке), а у него время жизни истекает, то он мог быть без внешнего воздействия "освежён" из БД низкоприоритетной ниткой. Всё это вместе повысило производительность в разы. БД была Oracle, кстати, и настроена вполне неплохо :-)

Re: Можно вопрос?

[piggymouse.livejournal.com]

Не подвергая сомнению Вашу точку зрения в целом, я хотел бы просто любопытства ради прояснить один момент.

Secundo: memcached как решение стоит 150 долларов (просто ставим в уже работающую машину дополнительный гигабайт оперативки) и порядка двух часов на всю процедуру внедрения — сборка, запуск, начали работать.

Адаптация существующих приложений (см. "Porting the Application"), очевидно, займёт несколько более двух часов. Вы не включаете адаптацию в понятие "внедрение" или я чего-то не понимаю?

Re: Можно вопрос?

[sergeax.livejournal.com]

очевидно, займёт несколько более двух часов

Вот лично для меня это глубоко неочевидно. Я специально посмотрел еще вчера все места в коде ЖЖ, где встречается обращение к memcache. Таковых мест наскреблось с два десятка в девяти файлах. Всей работы, при условии понимания механизма, как раз на искомые два часа.

Re: Можно вопрос?

[avva.livejournal.com]

Но оно всё использует библиотеку client-side на Перле, написание и отладка которой потребовала больше двух часов (хоть и не на порядок). Впрочем, та же библиотека может быть использована для других проектов на Перле, конечно.

Re: Можно вопрос?

[sergeax.livejournal.com]

И поставляется вместе с самим memcached, если я не ошибаюсь. По крайней мере какой-то Perl API там точно имеется.

Кстати, Анатолий, а каковы шансы у вашего демона быть успешно собранным под CygWin с mingw32?

Re: Можно вопрос?

[avva.livejournal.com]

Две библиотеки, от которых зависит memcached -- libevent и Judy. Judy должна по идее построиться под mingw32 без проблем, а вот насчёт libevent не уверен. В принципе ничего не мешает ей бежать под mingw32 и использовать стандартный поллинг на основе poll() (мы обычно компилириуем и запускаем memcached на машинах, к-е поддерживают более эффективный epoll() ), но сама компиляция может потребовать каких-то исправлений на уровне Makefile. А может и не потребовать.

В самом memcached единственное, что я могу представить в качестве проблемы - это вызов daemon() при запуске с ключом -d; его может не быть в mingw32, но его можно просто убрать или переписать с помощью fork().

В общем, я бы сказал, минут на 20 работы проверить, собирается ли сразу, и на час-два работы поправить, если собирается не сразу. Но следует учитывать, что: 1) poll() под Win32 наверняка будет не очень эффективным при большом количестве подключений (больше 300, скажем); 2) если под Win32 у mingw32 особенно тупой malloc(), то это может сказаться на перформансе.

Мечтательно

[sergeax.livejournal.com]

А вот что было бы на самом деле любопытно посмотреть, так это реализацию для Win32 с использованием IO Completion Port.

Re: Можно вопрос?

[s1m.livejournal.com]

Я нигде не предлагал Вам переход на какие-либо другие базы данных. С MySQL я никогда не сталкивался, хотя для некоторых видов приложений он должен быть более эффективен чем другие СУБД. Не думаю, что на простых запросах он сильно уступает (если вообще уступает) "настоящим"/"крутым"/как-их-там-ни-назови серверам БД.

Мне было интересно насколько Ваш подход эффективен. Похоже, что очень эффективен.

На мой личный взгляд, есть веские причины, позволяющие считать, что и в таком случае memcached может очень пригодиться.

Ну так я Ваш личный взгляд и спрашивал. Вы же автор, Вас и спросил. А мнение Брэда по этому поводу я уже читал (http://www.livejournal.com/community/lj_maintenance/60984.html) в lj_maintenance.

все же мне это немного странно

[qub.livejournal.com]

У "серьезных" баз (Оракл и даже Постгрес) ведь есть кеши не только запросов, но и самих тьюплов (низкоуровневых кусочков записей, как я понимаю) из таблиц. Т. е., вобщем, вся машинерия, и данные и откомпиленный сиквел запроса, могут храниться в памяти. Остается разница только во времени работы собственно самого откомпиленного кода, по сравнению с поиском по индексу в дополнительном промежуточном кеше. Казалось бы, раз уж степень нашего осознания происходящего в приложении дошла до того что мы в состоянии указать соответствие между некоторыми простыми ключами и всякими наборами данных, то можно это сделать и на уровне самой базы -- завести, к примеру, временные таблички с такими соответствиями. Тогда вышеупомянтуая разница должна стать малоощутимой.

Другое дело что в MySQL нет то ли всего, то ли части (я не спец) из описанного, так что вроде как раз был прав cmm выше, насчет залепления очередного отличия. Плюс на уровне кеша можно стараться развести риды с блокирующими их в MySQL райтами, что тоже очень, очень убыстрит все (ценой, правда, снижения надежности -- а как вылетит питание не дай бог, и все что уже было в кеше но не на диске окажется в нигде; как раз от таких случаев гарантированно страхуют тяжелые базы). Т. е. в конкретном раскладе LJ решение отличное, браво avva, но все же, кажется, поверх Постгреса или Оракла такая конструкция была бы лишней.

Разве что, ни в одной базе, насколько мне известно, нет никаких cache control директив; т. е. все эти кеши работают как черные ящики сами по себе, что иногда мешает (особенно при работе с кешем тьюплов, кеш запросов еще можно как-то оттьюнить меняя запись запроса).

Еще вспоминается главное ноу-хау Альтависты, Very Large In-Memory Index или как-то так, времен когда трава была зеленей, поиск медленный а память дорогая.

Re: все же мне это немного странно

[nine_k]

Пусть у нас есть объект, требующий для совего поднятия из БД 10-15 запросов. Пусть БД настроена совершенно идеально и пересылает результаты запросов сразу из своего кэша. Остаётся оверхед на формирование 10 запросов через интерфейс (DBI в случае LJ, JDBC в моём), разбор этих запросов БД, и преобразование данных из кэша БД обратно в формат интерфейса. В случае, когда БД выдаёт данные действительно практически мгновенно, этот оверхед, похоже, становится одной из основных задержек. Если же БД хоть иногда промахивается по кэшу, всё становится ещё суровее.

Т. е., imho, memcached решает (также и) проблему кэширования сразу нужного набора данных, в отличие от кэширования мелких кусочков с оверхедом на сборку из них целого.

Насчёт альтависты -- вон гугль вообще весь в памяти и ничего :-)

я, признаюсь,

[qub.livejournal.com]

не смотрел на доки memcached, но как я понял из переписки в частности в этом треде, понимание приложения у разработчиков LJ находится на том уровне что они в состоянии выдать вместо набора sql-запросов один уникальный ключ, по которому memcached вытаскивает большой объект.

я сравнивал этот вариант с (временным) хранением аналога таблички соответствий (которая должна быть внутри memcached) непосредственно в базе. т. е. в базе было б написано -- уникальный ключ в понятиях логики приложения равен такому-то набору таких-то разношерстных записей (адресованных сразу по уникальным индексам). вкупе с поднятым кешем тьюплов это, на мой взгляд, дало бы примерно тот же эффект что и memcached.

некоторую часть, предположительно имеющуюся в memcached -- менеджмент самой таблички уникальных ключей и соответствующих им записей -- все равно пришлось бы написать; но не нужно было б писать логику кеширования, она пришла бы с кешированием тьюплов в базе.

вполне возможно, я что-то упускаю -- я очень поверхностно знаком со всеми сторонами предмета, и моя конструкция представляется мне шаткой. хотелось бы как раз где именно она шатается.

Re: Можно вопрос?

[avva.livejournal.com]

Не подумайте, что я от Ваших вопросов отмахивался. Просто я действительно мало что понимаю в БД и стараюсь на эту тему поменьше спекулировать.

Re: я, признаюсь,

[sergeax.livejournal.com]

Мне кажется, что это все — разговоры в пользу бедных. Мы ясно видим, что дешевейшее в исполнении и масштабировании решение (две недели программирования-отладки, $150 за гигабайт кэш-памяти) подняло производительность ЖЖ в разы. Особенно хорошо это видно прямо сейчас, когда проснулась Америка, а лента френдов, тем не менее, строится незначительно дольше, чем в воскресенье днем.

Вы же высказываетесь в том духе, что решение за несколько десятков тысяч долларов, буде поднято и должным образом настроено, возможно, смогло бы решить эту проблему, а возможно и не смогло бы — надо смотреть саму задачу вживую. Как-то в таком свете меня много больше устраивает готовое решение Анатолия. :)

[sergeax.livejournal.com]

Да, вот самое главное, пока спать не пошёл. Анатолий, как вы думаете, Брэд вообще понимает, что масштабировать ЖЖ до бесконечности невозможно? Что рано или поздно придётся выпустить его (и сопуствующие денежные потоки) из рук и превратить в распределенную систему, близкую к newsgroups — когда раскиданные по всему миру серверы обмениваются между собой записями, держат каждый у себя свой, уникальный их набор, строят для своих и только своих клиентов френдленты и рассылают сообщения о полученных комментах, и лишь обсуждение ведется та том сервере, где было создано исходное сообщение? И что потребуется механизм типа PGP для реализации френдования, когда каждая закрытая запись шифруется с ключами всех тех, кто имеет право ее читать? И что понятие security несколько изменится - удаление записей потеряет смысл, толстые серверы смогут хранить все редакции одной и той же записи, единожды написанную запись будет не вырубить топором и не защитить от вездесущих поисковиков и data miners?

Впрочем, это уже будет не ЖЖ.

Re:

[avva.livejournal.com]

Впрочем, это уже будет не ЖЖ.

Вот именно. А что будет с ЖЖ -- будем посмотреть.

Сергей,

[qub.livejournal.com]

все же удивительно насколько мои слова смогли быть истолкованы превратным образом. Я же написал парой комментов выше -- отличное решение в ситуации LJ, спасибо avva еще раз.

Мне было интересно это решение положить в общую картину (как и вам, только с другого края). Я специально написал ответ на коммент 9000, который описывает возникновение похожей идеи в другом совершенно контексте (поверх уже данного в условиях задачи Оракла). И предложил сравнить дополнительный леер типа memcached с возможными дейстивями поверх собственно такой тяжелой базы. Ну интересно же понять как и какая именно логика и алгоритмы могут быть раскиданы по разным слоям, и к чему это может привести, да? мне интересно.

[(Anonymous)]

Эх Аркадий, а еще в газеты пишете :)

(далее - голосом Дроздова)
Кроме программистов в непосредственной близости от баз данных обитают такие виды млекопитающих, как системные аналитики, алгористмисты и, naturally, администраторы-баз-данных, они же ди-би-эй, ну и, конечно, писатели. Технические. Technical writers то есть :)

[hornedkavu.livejournal.com]

Много лет уже прошло... Не побоюсь стать некропостером... Но все таки...
Ну что же, Анатолий, как вы считаете - тот самый "момент номера" пришел? =)

Спасибо вам за мемкэш ;-)

Проектирование систем технической безопасности

[(Anonymous)]

Читаем мои заметки - "[url=http://alarmworld.ru]охранные сигнализации[/url]". Актуальные статьи