Заметки с 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 осуществляет перловый демон "Кеша".