О чём этот пост

1. Это пост-обзор вариантов управления моделями данных, известных автору, на основе опыта, слухов, и чтения инструкций
2. Также этот пост — попытка классификации существующих вариантов управления моделями данных
3. Напоследок приводится идея и начальные штрихи в реализации системы управления моделями данных, которая не должна содержать недостатков предыдущих

Определения и ограничения

Предполагается, что читатель является (или когда-нибудь станет) разработчиком Enterprise Application, которому часто нужно писать быстро и качественно, но не боящегося лезть в дебри JPA/JTA/RMI чтобы «подкрутить напильником» особо тонкие места.

Данные — то, что хранится в базе данных приложения. Данные о клиентах, пользователях, заказах и т.п.

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

Многие недавно пострадали от одновременного падения тысяч серверов сначала в пожаре на hosting.ua, а затем при отключении на McHost. Зацепило и меня. Денег на умерших сайтах я не зарабатывал, однако почта постоянно нужна для деловой переписки. Несмотря на то, что почта у меня перенесена на Google (или как вариант на Yandex), ни одно письмо не могло до меня дойти, т.к. вместе с серверами умерли и Name-сервера, и отправители просто не могли прочитать MX-запись для моего домена. Итого, 26 часов я просидел без почты объясняя всем людям, с которыми я работаю, что им нужно дублировать все письма на другой ящик — достаточно унизительно и не профессионально.

Как же заставить почту работать даже если все сервера хостера лежат?

Многих хабровчан интересует вопрос Time Management'а. Именно этим объясняются высокие рейтинги статей, описывающие разные методики и технические средства с ними связанные. Попробую и я внести свою лепту, рассказав о том, как на базе нескольких линуксовых машин (3 х Ubuntu 9.10) мной реализована и используется последние полгода система планирования и составления списка задач (Getting Things Gnome! 0.2.3 aka GTG), хронометраж (Time Tracker 2.29.92 aka Project Hamster) и синхронизация конфигурационных и файлов баз данных с помощью Dropbox for Linux v.0.7.110 , так сильно любимого на просторах хабра. Первые два приложения написаны на питоне, что делает их ещё более привлекательными, т.к. позволяет самому быстро разобраться в коде и подвинтить их (приложения) под себя. Хотя и в стандартной конфигурации они справляются с поставленными задачами очень даже не плохо.

Во время dot com бума мы с друзьями основали стартап, где я был техническим директором. Мы разработали систему управления знаниями. Это была комбинация блогов, wiki, системы управления документами, социальных закладок. Мы начали в 1999, что было несколько рановато для wiki и блогов (Movable Type вышли на рынок в 2001). Социальные закладки, по сути, были точно такими же, как станет впоследствии Delicious. Помимо этих новых и замечательных идей (по крайней мере для 1999 года) у нас было три отличных особенности:

• Всему можно было присвоить метки (tags): навыкам, людям, ссылкам, документам, постам в блогах, страничкам в wiki. Что-то, что теперь называется фолксономия. Метки могли соотноситься с другими метками и формировать онтологии. Метки могли ссылаться на другие документы, посты, людей.
• Всему можно было поставить свою оценку от 1 до 5.
• У нас был умный нечёткий поиск, основанный на метках и оценках. Например, при поиске «люди со знанием Oracle» в выдачу также попадали специалисты по SQL Server'у — например, чтобы укомплектовать команду, если не было свободных гуру Oracle.

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

Принесли мне намедни винчестер прямо в упаковке и озадачили оперативным клонированием системного диска одного из серверов. Задача, в целом довольно тривиальная, и легко выполнимая. У каждого наверняка есть методика подобного рода действиям, не знаю лучше или хуже мой подход, но поделиться, думаю, им стоит.
Вводная:
* сервер с linux
* все разделы на XFS
* загрузчик GRUB 0.97
* оригинальный диск /dev/sda, клонируем на /dev/sdb
* разделы /dev/sda[1,5-7] (общая полезная информация ~1GB)

thebigpic.org

Сколько бы ни говорили, что логи способны полностью заменить отладку, увы и ах — это не совсем так, а иногда — совсем не так. Действительно, иногда и в голову не придет, что надо было писать в лог именно эту переменную — в то же время, в режиме отладки можно часто просмотреть сразу несколько структур данных; можно, в конце концов, наткнутся на проблемный участок абсолютно случайно. Поэтому иногда отладка неизбежна, и часто она способна сэкономить очень немало времени.

Отлаживать однопоточное Java приложение просто. Отлаживать многопоточное Java приложение — чуть сложнее, но все равно просто. Отлаживать мультипроцессное Java приложение? С процессами, запущенными на разных машинах? Это определенно сложнее. Именно поэтому все руководства по Hadoop рекомендуют обращаться к отладке только и исключительно тогда, когда другие опции (читай: логгинг) исчерпаны и не помогли. Ситуация зачастую усложняется тем, что на больших кластерах у вас может и не быть доступа к конкретным map/reduce узлам (именно с этим вариантом я и столкнулся). Но давайте решать проблему по частям. Итак…

Сценарий первый: локальный Hadoop

Самый простой вариант из всех возможных. Локальная инсталляция Hadoop — все выполняется на одной машине, и более того — в одном процессе, но в разных потоках. Отладка эквивалентна отладке обычного мультипоточного Java приложения — что может быть тривиальнее?

Как же этого добиться? Мы идем в директорию, где у нас развернут наш локальных Hadoop (я полагаю, что вы умеете это делать или умеете прочитать соответствующую инструкцию и уже теперь с этим справитесь).

    $ cd ~/dev/hadoop
    $ cp bin/hadoop bin/hdebug
    $ vim bin/hdebug

Наша задача — добавить еще одну опцию JVM, где-то в районе 282-283 строки (в зависимости от версии, номер может и измениться), сразу после того, как скрипт закончил формировать $HADOOP_OPTS:

Чем может помочь интернет автомойке на улице с низким трафиком, которая еле-еле сводит концы с концами?

А если собрать клиентов через Яндекс Директ?
Задание для рекламщика не интересное, не креативное.
Итак.
Что сделали:
Шаг 1. Проанализировали потребителя — кто может быть потребителем услуг, как далеко готов ехать клиент ради мойки или других услуг, как сделать клиента постоянным.
Шаг 2 Проанализировали окружение — сколько конкурентов вокруг, какие они оказывают услуги, какова их стоимость, какова их загрузка, сильные и слабые стороны, опыт конкурентов удачный и не очень, конкурентные преимущества.
Шаг 3 Приступили к написанию кампании в Яндекс Директе.

Пишем первое слово: автомойка.

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

Все это предстояло перенести на автоматизированную основу. Самое интересное – разработку оплачивали вполне пристойно, а вот на железо денег не выделили вовсе – попросили чтобы все это подняли на имеющемся железе. Парк машин состоял из десятка морально мертвых монстров и именно на них надо было поднять БД-сервер и бэкап сервер.

Первоначально необходимо выяснить цель визита и полномочия сотрудников на совершение определённых действий. Данные полномочия могут быть выражены в различных документах (постановлениях начальника органа дознания, суда, следователя, дознавателя) в зависимости от того, каким законом регламентированы их действия (доследственная проверка в рамках ст. 144, 145 Уголовно-процессуального кодекса РФ или деятельность в рамках Законов «О милиции», «Об ОРД»).

Собственно, сегодня был запощен топик "Сравниваем производительность MongoDB и MySQL на простом примере", в котором указывалось, что MongoDB превышает по производительности MySQL в разы. Хех, когда такое пишут — я сразу лезу проверять и сомневаться. Я полез в исходники оригинального теста (спасибо за публикацию). И как оказалось автор оригинального топика сделал ошибку в три символа и на самом деле не все так:

1. В оригинале: MongoDB быстрее MySQL пишет в 1.5 раза (ДА, правда у меня в 3 раза)
2. В оригинале: MongoDB быстрее MySQL читает в 10 раз (НЕТ, на самом деле — MongoDB примерно на равных плюс-минус 10-30%)
3. InnoDB vs MyISAM — плюс-минус (в оригинале не тестировалось)

Сравнение здесь происходит только как key-value storage (запись-чтение по primary key).


На графике — число операций в секунду, (больше — лучше), шкала логарифмическая.
Последняя строка — то, что тестировал автор оригинального топика (неправильное, не в критику — все мы ошибаемся и учимся).

А теперь подробнее об ошибке…

Уникальное в своём роде дело начал рассматривать суд Нью-Джерси. Группа мошенников и программистов обвиняется (акт, PDF, 43 стр.) в том, что с 2002 по 2009 годы заработала около $25 млн на нелегальной перепродаже билетов на концерты, спортивные состязания и другие мероприятия. Потерпевшая сторона — онлайновые сайты по продаже билетов, в том числе Ticketmaster, Musictoday и Tickets.com.

Афера примечательна тем, что мошенники наладили автоматическую систему по покупке билетов на онлайновых распродажах. Они зарегистрировали две фирмы (Smaug и Platinum Technologies) исключительно для покупки диапазонов IP-адресов и съёма серверов в аренду, а также для регистрации около 1000 телефонных номеров. Через всю эту инфраструктуру осуществлялась покупка билетов якобы от уникальных покупателей.

Вся афера была основана на взломе визуальных и звуковых CAPTCHA. Мошенникам удалось эффективно взломать систему reCAPTCHA при помощи перехвата пользователей, пытающихся логиниться на Facebook, где используется такая же система, и автоматическое составление базы правильных ответов.

Хороший код

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

Основное правило

Я считаю, что читаемым является код, в который можно не вчитываться.
То есть, пары-тройки строк дожно быть достаточно, чтобы сказать, что делает класс или метод. Ещё пары-тройки — чтобы примерно сказать, как он это делает.

Прочие замечания

Я заметил, что есть ещё несколько довольно общих правил, которые делают код симпатичнее.

Рассуждения на тему систем очного обучения и организации образовательного процесса 2.0
… Во многих ВУЗах есть факультет дистанционного обучения, на котором, как правило, используется специальное ПО для обеспечения и облегчения процесса обучения. Почему же, в этих ВУЗах, не используются ПО для облегчения ведения процесса очного обучения? Система очного обучения(СОО) смогла бы избавить преподавателей от ненужной бумажной волокиты, от хранения тонн бумажных отчетов студентов, от составления списков прогульщиков, выставления рейтинга, дала бы дополнительные возможности такие, как: оповещение студентов(рассылка, новости, блог преподавателя), статистика по студенту/группе/потоку/месяцу/году.
Итак, давайте поговорим о ПО для очного обучения…

Введение

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

Сегодня мы поставим MongoDB, ниже рассмотрим свежеиспеченный ХабраЛоггер и пошпионим за главной страницей Хабра в реальном времени.

Введение

Коллеги, при разработке приложений, мы каждый день сталкиваемся с потребностью в гибком хранении информации (обновлении, поиске по ней, и т.д.). Класс продуктов, которые решают этот круг задач, как все мы знаем — Базы данных. Но что это такое в нашем понимании? У многих «база данных» твердо ассоциируется с MySQL, таблицами и SQL-запросами. И это устраивает до определенного момента. Действительно, реляционные базы данных дают массу преимуществ в работе: поскольку данные имеют сильную связанность, не нужно контролировать целостность базы данных. Используя простой под-запрос можно выбрать количество комментариев к каждому посту в блоге. Используя JOIN нетрудно делать сложные связанные выборки и получать данные сразу о нескольких сущностях.

Рано или поздно многие крупные проекты сталкиваются с проблемами производительности при постраничной навигации по записям. Некоторые из них решают эту проблему ограничением количества доступных для просмотра записей (скажем, не больше 1000). Вполне приемлемое решение. Но в этом случаем могут возникнуть проблемы с индексированием сайта сторонними поисковиками, которые и представляют наибольшую угрозу. В этой статье я хотел бы отказаться от привычной для всех панели навигации вида «1..2..3..4..» в пользу простой «вперед… назад» (будет проще объяснить), но это не проблема реализовать подобное и с первым вариантом.
Более точно определить тему, назвав, какое количество записей считать достаточно большим для появления тормозов, не получится, так как эта цифра для всех разная и сильно зависит от того, насколько быстрые у Вас жесткие диски, сколько памяти, и какая часть Ваших данных уже закеширована в ней и тд. Но если Вы и Ваши сервера ощущают, что n-ная страница при выводе даётся тяжелее первой, и при этом не знаете, что с этим делать – статья для Вас. Но для начала, я хотел бы на пальцах объяснить, почему ОНО работает медленно.

Кстати, тест происходит на виртуальной машинке, работаю я с СУБД под рутом, версия MySQL – 5.0.32.

Условия

Мы используем MySQL для хранения любых данных FriendFeed. Наша база данных растёт вместе с числом пользователей. Сейчас у нас более 250 миллионов записей, это записи пользователей (post'ы), комментарии, оценки («likes»)

По мере того как росла база данных, мы время от времени имели дело с проблемами масштабируемости. Мы решали проблемы стандартными путями: slave-сервера, используемые только для чтения, memcache для увеличения пропускной способности чтения и секционирование для увеличения пропускной способности записи. Однако, по мере роста, использованные методы масштабируемости привели к затруднению добавлению новой функциональности.

В частности, изменение схемы базы данных или добавление индексов к существующим 10-20 миллионов записей приводили к полной блокировке сервера на несколько часов. Удаление старых индексов требовало времени, а не удаление ударяло по производительности, так как база данных продолжала использовать их на каждом INSERT. Существуют сложные процедуры с помощью которых можно обойти эти проблемы (например создание нового индекса на slave-сервере, и последующий обмен местами master'a и slave), однако эти процедуры настолько тяжелые и опасные, что они окончательно лишили нас желания добавлять что-то новое, требующее изменение схемы или индекса. А так как наши базы сильно распределены, реляционные вещи MySQL как например JOIN никогда не работали для нас. Тогда мы решили поискать решение проблем, лежащее вне реляционных баз данных.

Существует множество проектов, призванных решить проблему хранения данных с гибкой схемой и построением индексов на лету (например CouchDB). Однако, по-видимому ни один из них не используется крупными сайтами. В тестах о которых мы читали и прогоняли сами, ни один из проектов не показал себя стабильным, достаточно зрелым для наших целей (см. this somewhat outdated article on CouchDB, например). А все это время MySQL работал. Он не портил данные. Репликация работала. Мы уже в достаточной мере понимали все его узкие места. Нам нравился MySQL именно как хранилище, вне реляционных шаблонов.

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

Disclaimer

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

Недавно я задал вопрос — было бы интересно хабралюдям почитать о том, как писать под Google AppEngine? Хабралюди сказали что да, интересно — ну я и решил начать. В этой статье мы рассмотрим следующие вопросы:

1. Ультра-краткое введение в Google AppEngine (GAE), что это такое и с чем его едят
2. Возможности и ограничения GAE
3. Супер-краткий обзор архитектуры GAE-приложения
4. Разработка минимального приложения с аутентификацией
5. Разработка более сложного, реального приложения на основе MyTwiLinks

Начнем с самого начала, с самого простого — совсем для нубов (каковым я и являлся, когда начал разбираться с GAE), постепенно продвигаясь к более сложным концепциям, заканчивая грязными хаками на тему «как быть, если нельзя, но очень надо» (почти наверняка не успеем в рамках этого поста, но доберемся обязательно).