Подписка на RSS


NoSQL решения имеют одну общую черту — они в основном спроектированы для горизонтальной масштабируемости. Поэтому неудивительно, что для многих приложений в мире Twitter выбирают хранилища, основанные на NoSQL для их уровня данных.

В статье описывается утилита для тестирования Sysbench. Утилита подходит как для тестирования ОС, так и для СУБД. Sysbench можно использовать для проверки CPU, оперативной памяти, файловой системы, потоков. Приводится реальный пример тестирования MySQL в двух конфигурациях: при включенном сбросе лога на диск после каждой транзакции и при выключенном. Результатом является двукратное увеличение пропускной способности.

Ссылка: Sysbench – тестируем производительность MySQL и платформы


James Turner взял очень содержательное интервью у Joe Stump (технический директор SimpleGeo и ведущий разрработчик архитектуры Digg), в котором Joe, как обычно, дал несколько инсайдерских комментариев о своем опыте использования Cassandra и MySQL. Так как Digg начинал с использованием MySQL-ориентированной архитектуры и недавно на полной скорости начал переходить на Cassandra, то его наблюдения, выученные уроки и мотивы для перехода особенно ценны.

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

Ссылка: Анализ производительности в SQL Azure


Развертывание на одном сервере может быть сделано одним скриптом, который выполняет множество ssh/scp команд. Если у вас несколько больше серверов, вы можете запустить его в цикле последовательно или запустить несколько процессов параллельно. Однако, в какой-то момент это станет неуправляемым, особенно если вам надо обновлять несколько датацентров одновременно. Так как же такие компании как Twitter выпускают свои релизы?

Cовременные реляционные СУБД предлагают универсальные решения, в которых часто нет необходимости. В статье приводится сравнение СУБД MongoDB и MySQL по характеристикам и по производительности с помощью небольшого теста на 5000 выборок. В конце делается вывод, что использование Mongo DB оправдано, когда не нужна, например, возможность сделать JOIN, потому что язык запросов Mongo DB уступает SQL в гибкости и возможностях. Но эта гибкость не нужна во многих задачах. Mongo DB подходит почти под любой класс задач, где не требуются сложные выборки.

Ссылка: Mongo DB – документо-ориентированная база данных и MySQL


Последние шесть месяцев были очень интересными для команды разработчиков Digg. Мы решили все переписать с нуля. Мы не только переписывали весь код приложения, но и запускали новую серверную и клиентскую архитектуру. Ну и, чтобы не мелочиться, мы заодно меняли большую часть нашей инфраструктуры и переезжали с LAMP.

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


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

Каждый раз, когда у меня появляется возможность рассказать моим коллегам о крутости App Engine, мне причиняет боль необходимость говорить: “… но вы не можете делать JOIN’ы”. Я знаю насколько полезными могут быть JOIN’ы, потому что я использовал их много лет до того, как начал работать на App Engine. В последнее время я раздумывал над тем, что должен быть способ заставить их работать. Хранилище данных App Engine гарантирует, что производительность запросов масштабируется с ростом размера результирующего множества, а не всего множества данных. Таким образом запрос, возвращающий 100 записей, должен выполняться за одинаковое время и на тысяче записей и на миллионе. Это означает, что мы не можем вычислить полное декартово произведение во время запроса, потому что это потребует просмотра всех данных в n объединяемых таблицах, и если мы просматриваем все данные, наша производительность оказывается связанной с размером множества данных. Тем не менее похоже, что мы можем что-то с этим сделать.

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