Интересный подход к разработки сайтов.

Антон, тебе должно быть особенно интересно!

Базовая архитектура веб-приложения на Backbone.js / JavaScript / Хабрахабр

Заметки с highload++

Извините, пока выкладываю без редактирования и комментирования. Может дойдут руки когда нибудь причесать. Если кому будет что-то интересно задавайте наводящие вопросы в комментах, я постараюсь раскрывать темы, если смогу.

3 октября

### Facebook

Mysql tools

1. Для отладки
    - Shadows
    - pmysql
    - Query Comments
    - Общие логи

2. replication

    - better slave prefetch
    - parallel slaves (oracle)


### Design and Implementation Erlang VM

- incremental/concurent garbage collector (BEAM)
- erjang (Stop-The-World GC)

### Почему не стоит использовать MongoDB

1. MapReduce
- медленный
- однопоточный
- BJSON -> JSON - медленно

2. Memory Mapped Files
- плохо если индексы вытесняются из памяти и это не контролируется
- "Дыры" в файлах из-за удаления (физически не удалён до следующей
 дефрагментации). Нужно делать compact коллекции (дефрагментация)

3. Нельзя ограничить достпуной памяти

4. Глобальный write lock
- блокировки при миграции чанков
- во время миграции повисает set_shard_version()
-

5. Оптимизатор запросов
- только один индекс
- выбирает план эмпирически

6. Шардинг
- все шарды равноправны, это плохо, если машинки разные. Хорошо бы задачать
 вес
- нет распределения коллекций

7. Мониторинг
- нет аналогов New Relic RPM
- но есть MMS (MongoDB Monitoring Service)


Удобно использовать когда много мелких udate`ов.

4 октября

### Redis в Stype

1.vbuckets - mapping виртуальных шардов на реальны сервера
2. Распиливание шарда
- фильтрация протоколя репликации
- важно чтобы в командах были ключи по которым можно поределить шард.
-

3. Фильтрация RDB
- RDB добиваются нулями до исходного размера
-

4. Прокси на twisted
- Легко и быстро

5. В Redis используется оптимизации хранения данных.

### Apache Cassandra

1. CAP теорема
- part. tolarance
- availability
- нет consistency

2. NoSQL - много разных

3. Amazone Dynamo
- распределённый hash-map
- get/set
- полная распределённость, нет координатора
- DHT в торрнетах - аналог

4. Архитектура Cassandra
- Token Ring
-

5. Запись
- клиент не знает как распределены ноды
- комманда отправляется на произвольный сервис
- это сервер становится координатором
- далее команда перенапрвляется на нужный сервер
- клиент выбирает критерии успешности (на одну или на все)

5. Чтение
- команда передаётся произвольному серверу
- далее начинаем опрашивать серверы

6. BigTable
` - есть колонки, но они не регламентированы
- есть master, является координатором чтения/запись
- клиент получает от мастера, где взять данные, и сам идёт за ними.
- новые данные сначала memtable, потом сбрасываются в SSTable, к каждой SSTable приделан bloomfilter
- перилдически выполняется SSTable compact

7. Что откуда взяли
- Tocken Ring из касандры
- Хранение из BigTable
- Логическая структура (колонки) из BigTable

8. Распределённая репликация (между ДЦ)
- не понятно

9. Чтение
- Ближайшая реплика - snitch (simple, topology, dinamic)

10. Преимущества
- Очень быстрое чтение
- Легкость администрирования (один деммо

11. Недостаток
- Плохо реализован range scan
-

Thrift - использовать нельзя!!!

handoff - что будет? неконсистенси -
< > по колонкам

### Базы для аналитики (Авсеянко)

- Infobright !!!!!
- InfiniDB ( SQL, но компрессия только в Enterprize)
- MonetDB (Xquery, SQL)
- LicidDB

- C-Store
-
https://jira.rutube.ru/browse/DEV-632

### Одноклассники. Архитектура хранилища бинарных данных

- 1.6 млрд x 4 размер фотографий
- 200 Тбт

1. Было BerkleyDB + Remote Interface
- Всё плохо и медленно


2. Что хочется
- высокое чтение
- отсутствие spof
- резервирование
- гибкое расширение

3. рассматривали
- DFS
- HDFS
- Cassandar и пр

4. Что получилось
- Zookeeper
- Дисковое хранилище

5. Устройство сервера
- Работа с дисками а не с серсверами
- Мелкие файлы хранятся в сегментах, индекс хранится в памяти.
- NIO Server (Mina)

6. Сегменты
- Всегда одинаковые
- Место резервируется
- На одном диске запись всегда в один сегмент
- Данные в сегменте иногда пережимаются
- данные в памяти и на диске один-в-один

7. Индекс
- Собственная реализация
- Сбрасывается на диск
- Между снапшотами бинарный лог

8. Как работает?
- Уникальный ИД диска
- Фактор репликации 3, по разным дискам и серверам
- При записи используется "кворум"\
- Чтение 1 + 1 (на всякий случая идём на второй, есл ина первом нетЗ)

9. Маршрутизация
- Таблица с регионами
- даёт возможность не двигать данные


10. Zookeeper
- Хряняться IP серверов и ID дисков
- Хранится таблица маршрутизации
- Распределённая блокировка, при изменении таблицы маршрутизации


Александр Христофоров (odnoklassniki.ru/ah)

### CLodo

1. Ресурсы облака
- Load balance cluster
- Dynamic content cluster
- Database
- Cloud Storage (cache)
- Cloud Stojrage (storage)

2. Цели хранилища
- Надёжно хранить
- Удобно управлять, в том числе API
- ...

3. Выбран Swift
-

4. Перед swift поставили патченный nginx

- Что я должен сделать если хочу отдать файлы по FMS?
- А как устроен билинг в купе с кешированием?
- Как устроена инвалидация кеша на nginx?


5. Инвалидацию кеша nginx осуществляет перловый демон "Кеша".

SQL Shard + sphinx = NoSQL Fuck Off

Такой подход всё чаще встречается в описание систем.


Шардинг MySQL на Yii Framework / Yii — php-фреймворк / Хабрахабр

Sphinx — не только для поиска!

Управление тикетами Jira из Svn

Описание системы команд, помещая которые в комментарии коммитов, можно управлять состоянием тикетов Jira. ИМХО, очень удобно!

http://confluence.atlassian.com/display/JIRASTUDIO/Actioning+Issues+via+Commit+Messages

Ура, Fisheye!

Redis - no comments

Redis: лёгкие яблоки / NoSQL / Хабрахабр

Merge со скоростью мысли

Если не знакомы с тулзой svnmerge, очень рекомендую познакомиться. Она позволяет получать удовольствие от сихронизаций и мержей. Незаменимый помощник любого релиз-менеджера, работающего с svn. ;)
Идёт в стандартной комплектации любой современно сборки svn. Но может быть в отдельном пакете в зависимости от дистрибутива.

http://www.orcaware.com/svn/wiki/Svnmerge.py

Django Custom Fields: сквозь тернии к звездам

В процесс фикса одного бага выяснилась интересная вещь, хочу вот поделиться...
Как написано
В официальной документации написано, что если вдруг захочется создать кастомное поле, необходимо сделать следующие шаги:
1) создать класс CustomObject(object), представляющего значение этого поля
2) создать класс поля CustomField(django.db.models.Field)
3) определить в классе поля метод to_python(), который из значения, полученного из БД или из пользовательского ввода, конструирует тот самый CustomObject
4) определить в классе поля метод get_prep_value(), противоположный по функции методу to_python()
И все, но этого мало.
Как надо
Во-первых, CustomField может получить на вход to_python строковое представление объекта CustomObject, т.е. результат вызова CustomObject.__unicode__() - который, по умолчанию, выведет только полное имя типа объекта.
Во-вторых, django при попытке сохранения модели проверяет, изменились ли значения ее полей. На практике, происходит сжатие методом zip значения этого поля (мы еще помним, что значением CustomField является CustomObject?). Метод zip требует наличия у сжимаемого объекта итератора, в придачу к которому нужен еще и метод len().
Ну и факультативно...
Если итератор для объекта "ходит" по его текстовому представлению, то стоит его закэшировать и обновлять при изменении полей CustomObject, участвующих в создании текстового представления. Для этого поля объекта превращаем в свойства, в сеттерах которых выполняем обновление текстового представления.