7085
правок
Изменения
м
Нет описания правки
= ADD-2011 и другие конференции =
Был на второй конференции [http://addconf.ru/ ADD-2011]. Первая была в сентябре [http://addconf.ru/add_2010 в Ярославле], а вторая — в Питере чуть больше, чем через полгода. Конференция понравилась первый раз (смотри отчет [[отчетADD-2010]]) и совершенно не разочаровала второй. И организацией и уровнем докладов и, главное, обстановкой общения. Я этой весной был и выступал на многих конференциях (AgileDays, SoftwarePeople, ReqLabs) и потому могу сравнивать, и, на мой взгляд, для разработчиков, которые едут на конференцию за профессиональными контактами и обменом мнениями она, на мой взгляд, лучшая. Я сейчас попробую объяснить — почему.
У организаторов и программного комитета вполне определенная позиция — это конференция для того, чтобы разработчики общались и обменивались информацией по вопросам разработки. При этом конференция должна быть доступна, и интересна для широких слоев разработчиков, а не только для каких-то продвинутых гуру. И эту позицию выдерживают — по многим пунктам. Это проведение в пятницу и субботу, используется один рабочий день — в ряде организаций не охотно отпускают на конференции, а получить один день проще чем два. Это более низкая цена, чем на других конференциях, особенно если бронировать место заранее. И главное — это отбор докладов. Они — о практическом опыте разработчиков. При этом, что интересно, в ряде докладов предметом является использование тех или иных технологий, в том числе вендорских, например, MS Workflow Foundation, но когда об этом рассказывает не вендор, а разработчик реального проекта — это звучит по-другому.
Очень быстрый доступ по keyvalue. Но не только так — есть 15-20 операций чтобы строить запросы, включая существование элемента в массиве, соответствие всех элементов заданному множеству и т.п. Для конкурентной работы — команда find and modify — документ ищем и сразу меняем, что задано. База данных — кластерная. И в кластер сразу заложено, что есть мастер и дубль, который в случае чего подхватит. А еще есть журнал и лог транзакций — на случай падения. Из инструментов отладки — встроенный профилятор, плюс логирование запросов. К сожалению, есть ограничение — 16М на документ.
При проектирвоании проектировании важно правильно расшарить данные, это ключ к масштабированию. Shard key — идентифицирует данные в кластере, он не изменяется — только копирование, а если для коллекции — надо сохранить на диск и загрузить, только так. Пример — user по email. Другой пример — пусть есть ленты пользователей. Можно расшаривать по постам (событиям). А можно — по пользователям. В первом случае лента — распределенная, запрос ленты пользователя пойдет на много серверов. А при падении сервера получается лента с дырками. Во втором случае — вся лента с одного сервера, это эффективно по нагрузке. При проблемах — система не работает с одного сервера. Еще пример с фотками. timestamp в ключе фотки приведет к тому, что все фотографии, загруженные в один момент времени, ложаится в один кластер — не эффективно, потому лучше timestamp+user или timestamp+hash.
Наращиваются механизмы фоновой оптимизации. Например, балансировка чанков в фоновом режиме. Был интересный пример, как сжать таблицу без остановки — включаем вторую ноду-реплику, перелдиваем, сжимаем, переливаем изменения мастера, мастер выключаем.
