Главная > Open Source, PHP, веб-обзоры, Высокопроизводительная архитектура, ж. Хакер, СУБД > NoSQL: А ты уже отказался от SQL? Статья в журнал Хакер

NoSQL: А ты уже отказался от SQL? Статья в журнал Хакер

16 января 2010

128

Статья написана специально для журнала Хакер и опубликована на сайте журнала (в несколько сокращенной и отредактированной версии). Ниже я публикую свой оригинальный вариант,  без правок или ограничения на объем материала.

Первым кинь камень в того, кто скажет, что делать новый суперпроект надо с SQL базой данных.

Скажи честно, тебе ведь интересно, как устроены внутри все эти суперсайты, на которых висишь сутками ты и еще сотни миллионов человек сразу? Ну, это я говорю о Facebook и нашем вКонтакте, Google, Amazon, ebay, Twitter и десятки других сайтов, которые самые посещаемые в мире. Если ты делал уже сайты, то знаешь, что большинство веб-сайтов просто странички на PHP вместе с базой данных мускула (MySQL). База данных нужна для всего – там и новости и товары из магазина, статьи и  комментарии, и даже самое вкусное – логины и пароли пользователей, которые взламываются за пару секунд. Ты же даже не мыслишь о том, что сделать сайт без применения базы данных вообще – я говорю о реальном сайте типа форума или социальной сети, ну, на худой конец, магазин хакерских программ?

База данных – вширь и ввысь

В реальности так и есть – очень многие большие дядьки разработчики и архитекторы также думали, что без базы не обойтись, продолжая делать все более и более мощные сайты. Но потом все столкнулись с тем, что, сколько ни тужься, не придумывай всяких хаков и умных штучек, а базы данных плохой выбор, если у тебя сто миллионов посетителей. Ага, они тоже слышали о кластерах и распределенных системах, или даже об облачных вычислениях (можно почитать и у нас). Если надо, чтобы больше людей скачало новый порно-ролик Берковой, достаточно поставить еще пару серверов и скопировать на них файлы. А вот базы данных так просто не работают. Тут и появилась проблема масштабирования. Каждый решает ее по-своему.

Сначала ставят второй сервер, с него приложение только читает данные, записывая только на первый, а он уже сам, в фоновом режиме, переносит новые данные (это называется master-slave архитектура, ничего связанного с BDSM здесь нету!). Позже можно доставить еще сервер, и еще, но это уже не поможет, если писать надо много и постоянно. Ведь скоро каналы между серверами будут так забиты, что новые данные будут появляться на подчиненных узлах гораздо позже, чем это допустимо, а кому интересно ждать, пока же его комментарий появиться на странице (самые нетерпеливые тупо жмут рефреш, чем еще сильнее нагружают систему).

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

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

Скажи твердое НЕТ SQL-у!

А сайты то растут, пользователей много, счёт уже на десятки миллионов. Что же делать? А вот что – просто отказаться от обычной базы данных! Ведь что такое база данных то – это специальное хранилище данных (обычно, это просто файлы, но собственной структуры и кеш в памяти) c движком, который принимает от тебя команды в виде языка SQL и ищет все, что совпадает с ней. Особенно достают кривые руки разработчика или админа, когда для самого простого запроса «а сколько юзеров у меня на странице» приходится тупо перебирать весь список пользователей и проверять, у кого статус он-лайн. Ведь юзеров может быть реально много, а если ты еще не озаботишься правильными индексами, то на каждый такой запрос придется серверу доставать всю табличку с юзерами (а это может и гигабайт быть) и считать снова и снова. А если в этот момент Вася скинул своим френдам в ЖЖ ссылку на твой суперпроект и пришла еще тысяча юзеров, каждого из которых надо записать в базу? Все, капут серверу!

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

Ладно, оставим гуглу гугловское, а что делают остальные? Остальные используют key-value database! Что это такое? По сути, это максимально упрощенная база данных, даже, скорее, просто хранилище, где все данные сведены к обычной паре: ключ или индекс, и сами данные, которые, обычно представлены в виде простой строки, в некоторых случаях могут быть еще числа. То есть, все данные это просто список ключей и сопоставленных с ними строк данных. Что хранится в такой базе, ей совершенно неважно, это уже забота самого приложения. Интерфейс доступа к такой базе также максимально прост – обычно это простейшие команды типа get (получить данные по ключу), set (записать данные с ключем), delete (удаляет ключ и его данные), update (обновляет уже существующие данные).

Самым главным преимуществом является то, что если правильно все сделать, сложность таких операций (то есть, время вычисления результата) будет заранее известным и не зависит от объема данных или количества серверов. Также все операции обычно атомарные (в обычных SQL базах данных это называется транзакции) – задавая команду ты можешь быть уверенным, что она или успешно отработает или сразу вернет тебе ошибку, а другие данные останутся нетронутыми, при этом другие пользователи не помешают тебе, даже если будут пытаться сделать то же самое.

Ты познакомился с самым простым типом key-value баз данных. Существует много таких проектов, обычно, отличаются они типами данных, например, кроме строк, можно хранить числа или двоичные объекты (BLOB-ы), а также количеством команд-операций. Понятно, что описанные выше четыре операции самые простые, обычно поддерживается еще инкременент/декремент (счетчик в памяти), особо продвинутые могут хранить массивы и списки.

nonSQLdb_DHTschemaНа низком уровне такие базы строятся на базе хеш-таблиц и их разновидности – распределенной хеш-таблицы (DHT). Это просто обычная, хоть и большущая таблица, которая может автоматически распределяться на любое количество компьютеров и поддерживает поиск и получение данных баз знания, где они конкретно. Хотя обычно для быстрой работы данные хранятся в оперативной памяти, но некоторые сервера обеспечивают хранения на диске и бекап, так что после выключения такого сервера все данные сохраняются.

Светлые и темные стороны Силы

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

Несмотря на восторги, есть и сложности. Первая – это скудность возможностей работы с данными. Ага, это как раз расплата за скорость и расширяемость. Сервер знает только ключ и данные, к нему прицепленные, а вот что это за информация – номер кредитной карточки или дата регистрации – уже не ведает. Этим должно заниматься само приложение, так что просто взять и написать один SQL запрос и выбрать всех пользователей, которые регистрировались год назад и совершили больше одного платежа за это время, уже не получиться так просто. В базе просто нет такой возможности выборки по какому-либо признаку, кроме ключа.

Не спеши отворачиваться, это решается очень просто, за счет дополнительных данных (так же как в SQL-базе выделяются постоянные данные в отдельную таблицу-справочник). Проектировать сайт надо изначально под такие типы баз, иначе потом будут сложности – ведь то, что делается одной строкой на SQL, здесь потребует как нескольких запросов и обработки, так и предварительного форматирования данных при записи. Пока еще нет автоматических трансляторов SQL в key-value запросы, хотя работы в этом направлении ведутся.

Еще одним недостатком является требовательность к параметрам сервера, особенно любовь к оперативной памяти, которой, как известно, всегда мало. Обычно это решается хранением неиспользуемых данных на диске, например, так поступили в MemcacheDB, где скрестили популярный сервер memcache и базу данных BerkleyDB, которая используется как постоянное хранилище данных.
В Redis-е, молодой, но очень сильной разработке используют асинхронную запись в фоновом режиме на диск. Другие также не брезгуют использовать традиционные базы данных для хранения, ведь их совсем не видно за фасадом сервера и они работают локально, поэтому на скорость работы почти не влияют.

Сервера, подходи, выбирай, на любой вкус!

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

Memcached/MemcacheDB – наверное самый известный представитель семейства key-value DB. Многие используют его как кеширующую систему, что, по большому счету, то же самое. Он хранит данные в оперативной памяти, занимает места столько, сколько ему выделили и может объединяться с другими серверами, чтобы распределить данные между собратьями. Доступ к данным идет через UDP-порт и сокеты, но это очень быстро, а с выходом последней версии, 1.4, добавлен и экономичный бинарный протокол. Хотя, в facebook считают иначе и ускоряют, как могут, добиваясь нескольких сотен тысяч одновременных подключений! Кстати именно эта социальная сеть имеет самую большую инсталляцию Memcached-севреров – больше тысячи!

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

Project Voldemort – такой же мощный, как и Темный Лорд, только в царстве баз данных. Штука написана на Java и нацелена на распределённость, поэтому можно добавлять новые сервера без остановки, данные сами «расползутся». Также поддерживает, кроме обычного сетевого доступа, JavaAPI (кто бы сомневался) и различные сетевые протоколы, например, Google ProtoBuf или Thrift, что сильно экономит трафик и повышает скорость. Данные хранятся как в памяти, так и на диске, можно использовать и обычные базы данных, так что сбои питания никак не нарушат целостности. Сильной чертой является поддержка версионности, то есть каждая единица данных имеет историю версий и изменений, поэтому можно откатываться назад, если что-то записали не то или возникли ошибки.
Быстродействие также на высоте, в среднем, 10 – 20 тысяч операций в секунду, так что такой гигант, как LinkedIn не прогадал, используя кластер из серверов для своей работы.

Apache CouchDB - это уже тяжелое оружие из будущего! Шутка, CouchDB это представитель отдельного семейства баз данных, называемых документ-ориентированными. То есть, в этой штуке хранят документы, некоторую группу данных, которые вместе составляют один объект-документ. Например, статья (текст), краткая аннотация, имя автора, дата публикации и статус. По отдельности, это просто отдельные значения, а вот документная база позволяет их сгруппировать как один объект и производить над ним операции. Написана эта база на Erlang (просто замечательная платформа, если речь идет о расширяемости) и имеет HTTP REST-интерфейс или JSON API, так что можно получать данные сразу напрямую из JavaScripta-а на веб-странице! Кстати, она имеет встроенный язык запросов, какой ты думаешь? Да, JavaScript вместо традиционного SQ. А вот о промышленном применении пока не слышно, сильно уж экспериментальная разработка, хоть и очень интересная и перспективная. Поковыряй на досуге!

И, напоследок, расскажу о самой крутой системе, которая хоть молодая и простая, но мощнее всех предыдущих вместе взятых! А какие скорости – больше 100 тысяч запросов в секунду на простеньком сервере или мощном лаптопе! Речь идет о Redis – как он себя сам называет, сервер структурированных данных!

Он позволяет хранить не только обычные ключи и значения, но и списки, наборы данных (то есть, группы пар ключ-значение), а также производить всего одной командой (и с гарантированным временем выполнения!) сложнейшие операции над такими списками. Там, где для memcached надо писать вручную две, три или десяток команд и еще вычислять что-то в самом приложении, при использовании Redis-а можно обойтись одной! Поддерживается даже сортировка, что является самой сложной и практически не выполнимой командой для всех key-value баз (в отличии от SQL, где это самая тривиальная операция). Написанный на ANSI C, сервер умещается в паре десятков Кб исходных текстов (по лицензии BSD), работает на любой системе и сотворит с твоими данными чудеса. Команды посылаются по TCP или напрямую через telnet, есть и API или модули на любой вкус и язык (а я не буду скрывать, что автор класса-интерфейса на РНР, расширяющего возможности сервера еще сильнее).

А давай замутим… свой Twitter?!

Понимаю, что все, что я выше с таким трудом писал, это фигня, и хочется сразу что-то руками написать, почувствовать мощь новой технологии (ладно, не сильно новой, но все равно интересной).
Ты в курсе, наверное, что самый быстрорастущий сайт в мире сейчас это Twitter, даже мы о нем обстоятельно писали не так давно (ссылка на журнал). Как написать клон такого сервиса с использованием обычной SQL базы данных ты и так знаешь, нет там ничего сложного. А мы сейчас попробуем сделать то же самое, но без БД, используя сервер Redis. С кодом сложностей не должно возникнуть, HTML-странички также сам сверстаешь, а вот как использовать такую необычную базу внутри, я тебе сейчас расскажу.

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

Шаг 1. Аккаунты будем хранить в виде отдельных пар ключ-значение, где ключём будет логин пользователя, а значением – сериализированный массив (язык не имеет значения, например, РНР), в котором уже все о юзере, его имя, пол, дата регистрации и остальные данные. Вместо сериализации даже лучше использовать JSON – тогда мы вообще не будем зависеть от языка приложения, ведь JSON умеет обрабатывать любой современный язык программирования.

Команда SET admin “{name:’supervasya’,age:21,sex:’m’,registered:’27.07.2009’} ” – записывает нового юзера с логином admin. Теперь выполнив запрос GET admin мы получим JSON-строку с данными.
Для авторизации мы используем отдельное значение: SET admin_pass “md5(password)” – ключем здесь также логин, но с добавлением строки «_pass», а значение – md5 хеш пароля.

Авторизация будет в два шага (для надежности, но можно и в один). Сначала проверим, существует ли логин: EXISTS admin, если все ок (значит в базе есть такой юзер), извлекаем его хеш пароля для проверки: GET admin_pass. Саму проверку и сравнение хешей придется делать уже в приложении.
Не забудем счётчик всех юзеров (а то ведь SELECT COUNT() здесь нету): INCR count_user - увеличит счетчик юзеров на 1.

Если тебе захочется иметь весь список юзеров, придется раскошелиться на еще одну переменную, например, загнав все логины в набор (set): SADD all_user_list admin. Таким образом, в all_user_list у нас будет хранится список всех логинов, по которым можно извлечь профайл аккаунта.

Шаг 2. Теперь будем хранить все твои сообщения. Ключем в данном случае будет метка времени, потому что ключ должен быть уникальным, да и вряд ли ты будешь постить что-то чаще раза в секунду (нефиг спамить!). Можем просто создать ключ, используя логин и метку времени, например, admin_11232142135, и хранить его как отдельное значение вместе с сообщением:
SET admin_11232142135 “{author:’admin’,text:’моя супер статья!’,time: 11232142135,title:’статья!’} ”

Но чтобы облегчить себе жизнь, мы сделаем еще список, где будут хранится данные о времени постов каждого автора. Вот так: RPUSH admin_msgs 11232142135. Команда добавит в конец списка admin_msgs новое значение – метку времени твоего поста. Зачем? Для облегчения потом получения всех постов за определенное время или просто указанного количества, например, для постраничного вывода. Внутри списка даты уже отсортированные по времени, поэтому дополнительной сортировки ненужно.

Шаг 3. Если ты хочешь зафолловить (читать) Васю, необходимо сохранить логин Васи в твоем списке фоловверов. Для этого также применим списки, создав для каждого юзера список фолловеров: RPUSH admin_follow vasja. В списке admin_follow теперь будут хранится логины всех юзеров, которых хочет читать admin. Аналогично, если Вася хочет читать, что же про него пишет админ: RPUSH vasja _follow admin

Шаг 4. Выводим полную ленту сообщений. Выше мы уже умеем хранить все сообщения одного пользователя и хранить список тех, за кем он следит. Теперь выводим ленту сообщений, в которой будут как собственные сообщения юзера, так и все сообщения тех, за кем он следит. При этом, все сообщения должны идти в хронологическом порядке. Допустим, мы будем показывать только сообщения за последний час. Здесь уже немного сложнее. Сначала выберем список всех пользователей, которых надо показать. Для этого сначала получим количество наших фолловеров (длину списка): LLEN admin_follow. Допустим, мы получили 2 (админ отслеживает двух юзеров):
LRANGE admin_follow 0 1 – получаем в виде массива логины юзеров. Не забываем, что надо прибавить сюда и свой логин, так как наши сообщения также должны быть видны. Это уже придется делать самому приложению.

Далее, имея список логинов, нам надо выбрать все списки сообщений каждого юзера. К сожалению, для этого надо N раз вызвать команду LRANGE, указав ей каждый раз другой список (комбинацию логин игрока + _msgs). Конечно, в этом нет особо страшного ничего, ведь скорость работы Redis-а очень высокая, но этот момент может нуждаться в оптимизации. Например, есть команда KEYS которая ищет по паттерну все ключи и возвращает сразу список. Поэтому можно попробовать задать ей такое выражение, чтобы сразу получить все ключи сообщений (ведь они формируются через логин и метку времени, значит можно отфильтровать). Но это уже тебе как домашнее задание (на самом деле эта задача имеет несколько решений и не факт, что каждое из них самое лучшее).

Мы пока сделаем по-старинке, получив список сообщений для каждого юзера, программно сформируем из него список заранее подготовленных ключей для извлечения сообщений. Так как все сообщения идут по времени, достаточно полученный массив преобразовать из JSON-а в родной для твоего языка программирования и отбросить все значения, меньшие за текущее время минус 3600 (мы ведь за последний час выбираем). Если брать не за час, а просто последние 100, то задача еще более упростится.

Далее простым циклом формируем ассоциативный массив из комбинации логин + метка времени, где ключём будет метка времени (число, для обеспечения правильной сортировки), а значение – строка вида login_time (то есть так, как хранится у нас в Redis-e), а потом просто объединяем эти массивы. Язык сам позаботится о правильной последовательности, например, РНР так и сделает, используя команду array_merge и, если надо array_sort.

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

Последний штрих – сформируем команду к Redis-у на извлечение всех сообщений, ключи которых мы уже подготовили. У сервера есть волшебная команда, которой так не хватает другим популярным системам вроде memcached (там пытаются приспособить для этого теги) – MGET список_ключей, то есть одной командой получаем все ключи, имена которых передали. Остается только превратить наш массив в строку, разделителем служит символ пробела и все, мы сразу получим массив JSON-строк с сообщениями. Его даже сразу можно передать на веб-страницу, ведь с JSON умеет работать любой AJAX-фреймворк. На счет производительности не стоит переживать – операция декодирования JSON в родной для языка массив везде очень и очень быстрая, даже если речь идет о сотнях или тысячах преобразованиях.

Аналогично можно отобразить список всех фолловеров – ведь мы храним их в списке admin_follow, в котором хранятся логины, а значит, используя потом MGET команду, мы сразу достанем профайлы всех юзеров, за которыми следит админ.

Я ничего не сказал об удалении данных – ведь вдруг Вася окажется занудным типом или спаммером и ты захочешь отписаться от него. Для этого надо просто удалить из списка admin_follow его логин, что делает команда LREM, которой стоит передать только логин и все, нет больше Васи.

И что?

Сейчас реляционные базы данных (SQL СУБД) уже не правят миром, особенно если речь идет о высоконагруженных проектах или сайтах, где надо обслуживать клиентов просто мгновенно. Если раньше все проблемы пытались решить кешированием, то сегодня мы видим, как гиганты индустрии просто уперлись в ограничения баз данных и в поисках выхода попробовали посмотреть на традиционные кеши с другой стороны.

И получилось! Добавив чуточку смекалки и пару новых команд теперь можно делать почти все, что раньше требовало сложных SQL-запросов, используя всего пять-шесть команд. При этом не важно, один сервер, десять или тысяча, мы вообще никак не ограничены в масштабировании!

Конечно, не стоит сразу бросать любимый мускул и переписывать под Redis или MemcachedDB, но если ты делаешь сайт, где надо что-то делать быстро, очень быстро, как можно быстрее (ну типа чата, твиттера или онлайн игры, а то и биржевой системы) – попробуй посмотреть на мир key-value баз данных! Может это то, что надо! А SQL-базам оставим нудные дела вроде построения аналитики и анализа данных.

Основа основ или что такое DHT.

DHT (англ. Distributed Hash Table — «распределённая хеш-таблица») — это класс децентрализованных распределённых систем, которые обеспечивают поисковый сервис, похожий по принципу работы на таблицу хешей, и имеют структуру: (имя, значение), хранящиеся в DHT, а каждый участвующий узел может рационально искать значение, ассоциированное с данным именем.

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

DHT характеризуется следующими свойствами:

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

(информация из Wikipedia)

Как это работает в твоем торренте

Реализация распределенной сети в BitTorrent-клиентах основана на варианте DHT, называемом Kademlia.
DHT использует протокол UDP. Клиенты BitTorrent «слушают» тот же номер порта UDP, который они используют для входящих TCP-соединений. Если вы активно используете DHT, то открытие этого UDP-порта для доступа снаружи желательнo, но не обязательно — DHT будет работать и так.
Каждый подключённый клиент является в сети DHT отдельным узлом. У него есть свой уникальный ID (идентификатор), случайно выбираемый из того же 160-битного пространства, что и infohash’и торрентов.

Каждый узел хранит таблицу маршрутизации, содержащую контактную информацию о многих «ближайших» к нему узлах, и о нескольких более далёких. «Близость» двух узлов вычисляется из «сходства» их ID, и не имеет никакого отношения к их географической близости. Когда узел хочет найти пиров для какой-то раздачи, он сравнивает infohash этой раздачи с ID известных ему узлов, и затем посылает запрос тому узлу, чей ID наиболее похож на этот infohash. Тот узел возвращает ему адрес узла, чей ID ещё ближе к infohash торрента. Тогда наш узел посылает запрос тому новому узлу, и получает от него адрес следующего узла, чей ID ещё более похож на infohash торрента. Таким образом, запросы от клиентов, участвующих в раздаче торрента с определённым infohash, постепенно стекаются к узлам, чьи ID наиболее похожи на этот infohash. Эти узлы помнят предыдущие запросы, и всем следующим запрашивающим узлам вернут адреса предыдущих пиров с той же раздачи.
(информация из Wikipedia)

Ссылки и полезности.

Почитать о репликации можно в Википедии: http://en.wikipedia.org/wiki/Multi-master_replication

Для тех, кто любит делать руками: http://www.howtoforge.com/mysql5_master_master_replication_debian_etch

Немного о архитектуре Google: http://highscalability.com/google-architecture

А вот что там придумали вместо базы: http://labs.google.com/papers/bigtable.html

Что такое DHT - http://ru.wikipedia.org/wiki/DHT Именно на этой штуке работает твой любимый торреент, я имею ввиду протокол BitTorrent, а не сайт.

Все о Memcached: http://www.danga.com/memcached/ и http://memcachedb.org/

А вот и код кудесников от Facebook-а: http://github.com/fbmarc/facebook-memcached/tree/master

Официальный сайт: http://code.google.com/p/redis/ а мой класс - http://code.google.com/p/redis-ajax-chat

Все указанные команды можно набирать и проверить сразу в консоли, подключившись через telnet к серверу Redis.

Комментирование отключено.
Developers.org.ua