Статья "Недопонимание CAP-теоремы" и комментарии к ней свидетельствуют, что непонимание действительно есть. И связано оно не только с неправильным толкованием термина «partitioning», но и с ментальными ошибками на других уровнях. Попробую внести ясность.

В последнее время я довольно часто натыкаюсь на данную теорему. Она довольно давно доказана и про нее много чего написано. Однако каждый раз когда я натыкаюсь на распределенную систему, претендующую в описании на CA в терминах данной теоремы, т.е. систему в которой жертвуют Partition Tolerance в угоду Consistency и Avalability, я зависаю, так как хоть убейте не могу себе представить такого зверя. После долгих раздумий я все же пришел к выводу, что такая система бессмысленна, о чем и хочу порассуждать в данном топике.

Начитавшись в интернете про новые, простые, быстрые и масштабируемые технологии, захотелось их всех попробовать. Вдруг они окажутся лучше уже привычной мне связки postgresql + django + json-rpc.

Идея проекта

Так как никакой идеи не было, но был свободный домен uglyrater.org — пришлось делать рейтинг.
Суть проста: есть список пользователей, которым можно расставить + и -. Новые пользователи в рейтинг добавляются по адресу страницы ВКонтакте.

В прошлой статье я отказался от использования связки html + php + sql, оставив только html. Как и в прошлый раз, на html странице находится сразу все, что нам нужно, и остаётся только убрать лишнее, исходя из параметров поиска. Раньше мы это делали при помощи JavaScript, а теперь воспользуемся возможностями CSS.

Вступительное слово

В одном из своих рабочих проектов была необходимость во встраиваемой базе данных. И очень приглянулся Kyoto Cabinet. Всё с ним хорошо: и максимальный размер коллекции огромный, и скорость устраивает, и выбор типа хранилищ широкий, но вот только интерфейса для Эрланга у этого замечательного инструмента не оказалось.
Что же, из-за этого отказываться от библиотеки? Конечно, нет!

Хоть и некоторые писали относительно моего предыдущего топика MongoDB: Создание, обновление и удаление документов, что это пересказ офф. документации, я с этим не полностью согласен. Мне показалось, что информация в нём оказалось кому-то полезной, поэтому выкладываю продолжение.

Find — аналог SELECT в MySQL. Используется для выборки документов из MongoDB. Возвращает массив документов в виде коллекции, если документов нет — пустую коллекцию. Пример:

> db.users.find();

Вернёт всех пользователей из коллекции.

> db.users.find( { age: 27 } );

Вернёт всех пользователей, у которых возраст равен 27.

Tarantool — это крайне интересная база данных.
Представление о ней можно получить из доклада Константина Осипова Tarantool: как обрабатывать 
1,5 млрд запросов в сутки?

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

Как часть своей платформы для веб разработки Microsoft предоставляет и NoSQL решение для кэширования — AppFabric Cache. Одним из интересных режимов AppFabric Cache является High Availability — возможность создать кластер из кэш-серверов где в случае падения любого из них работа вашей службы не прерывается и все данные остаются доступными приложению. Когда вы создаете .NET веб-приложение без единой точки сбоя (single point of failure), использование такого кэш сервера кажется легким и естественным решением. Особенно здесь может радовать цена, так как AppFabric предоставляется компанией Microsoft бесплатно как часть своей операционной системы. Однако выбирая решение для кэширования полезно видеть не только то что на поверхности.