PG Day'14 Russia, PostgreSQL в avito.ru, Михаил Тюринpgdayrussia
Доклад был представлен на официальной российской конференции PG Day'14 Russia, посвященной вопросам разработки и эксплуатации PostgreSQL.
С момента старта проекта на PostgreSQL были возложены серьёзные задачи. Это во многом предопределило успешное развитие всего продукта. Вокруг СУБД выстроены основные компоненты архитектуры, при этом сами базы берут на себя львиную долю обработки пользовательских запросов. Набор фич и расширений, легендарная надёжность PostgreSQL, наличие встроенной репликации, средств резервирования и архивирования — весь потенциал нашел своё воплощение, а наличие открытого профессионального комьюнити не оставляет шансов к неэффективной реализации.
В докладе будет дан обзор развития подсистем, сосредоточенных вокруг PostgreSQL, представлены параметры и режимы функционирования. Будут описаны успешные решения в рамках отдельного PostgreSQL-кластера и при распределенной обработке данных, приведены текущие вызовы, связанные с продолжающимся активным ростом проекта.
Обзорный доклад про базовое внутреннее устройство любого современного поискового движка. Про сжатые списки документов и позиций, как затем с ними работает поиск совпадающих документов (и разные операторы), как устроено ранжирование найденных документов, как бывают устроены и работают с фильтрацией и агрегацией дополнительные (нетекстовые) атрибуты документов. По возможности, упоминание всех известных вариантов реализаций (как, вообще, можно, как сделано в Sphinx, как в Lucene).
Доклад о том, как мы добились идеально ровной балансировки нагрузки по кластеру из 200+ серверов, реализовали автоматический подбор весов и получили разброс CPU usage в 2,5% в пике трафика. Это позволило сэкономить нам около 40-50 серверов и улучшить время отклика мобильного сайта в пике нагрузки. Реализацию приведенного алгоритма мы выложим в open-sourсe. Доклад Юрия Насретдинова на Highload 2015.
PG Day'14 Russia, PostgreSQL в avito.ru, Михаил Тюринpgdayrussia
Доклад был представлен на официальной российской конференции PG Day'14 Russia, посвященной вопросам разработки и эксплуатации PostgreSQL.
С момента старта проекта на PostgreSQL были возложены серьёзные задачи. Это во многом предопределило успешное развитие всего продукта. Вокруг СУБД выстроены основные компоненты архитектуры, при этом сами базы берут на себя львиную долю обработки пользовательских запросов. Набор фич и расширений, легендарная надёжность PostgreSQL, наличие встроенной репликации, средств резервирования и архивирования — весь потенциал нашел своё воплощение, а наличие открытого профессионального комьюнити не оставляет шансов к неэффективной реализации.
В докладе будет дан обзор развития подсистем, сосредоточенных вокруг PostgreSQL, представлены параметры и режимы функционирования. Будут описаны успешные решения в рамках отдельного PostgreSQL-кластера и при распределенной обработке данных, приведены текущие вызовы, связанные с продолжающимся активным ростом проекта.
Обзорный доклад про базовое внутреннее устройство любого современного поискового движка. Про сжатые списки документов и позиций, как затем с ними работает поиск совпадающих документов (и разные операторы), как устроено ранжирование найденных документов, как бывают устроены и работают с фильтрацией и агрегацией дополнительные (нетекстовые) атрибуты документов. По возможности, упоминание всех известных вариантов реализаций (как, вообще, можно, как сделано в Sphinx, как в Lucene).
Доклад о том, как мы добились идеально ровной балансировки нагрузки по кластеру из 200+ серверов, реализовали автоматический подбор весов и получили разброс CPU usage в 2,5% в пике трафика. Это позволило сэкономить нам около 40-50 серверов и улучшить время отклика мобильного сайта в пике нагрузки. Реализацию приведенного алгоритма мы выложим в open-sourсe. Доклад Юрия Насретдинова на Highload 2015.
Open source субд глазами обычного программистаSlach
Попытался "быстренько" пробежаться по всем СУБД с которыми работал за 20 лет и постараться вложить слушателям мысль что СУБД надо выбирать под нагрузку
и что для СУБД надо знать "алгоритмы" и "эксплуатацию"
Кэширование данных в web приложениях. Использование memcached / Юрий Красноще...Ontico
Каждый разработчик web приложений рано или поздно сталкивается с довольно типичной проблемой: перед ним стоит задача построить фабрику по производству омнониевых торсиометров.
Фабрика производит омнониевые торсиометры очень быстро, но для калибровки прибора (как известно) необходим омноний, за которым приходится летать на Андромеду.
Пока корабль летит до Андромеды, фабрика простаивает.
Самый очевидный выход из ситуации - построить склад омнониума прямо рядом с фабрикой.
Терминология кэширования
Выбор места для кэширования в WEB
Выбор данных для кэширования
Кэширование на стороне бэкенда
Отдельный кэширующий сервис
Пара слов о memcached
Пара слов о Redis
1. Вводная часть: базовые понятия и определения
1.1. Что такое “файл”
1.2. Роль файлов в современном мире, миф о ненужности файлов
1.3. Файловое хранилище АКА файловая система
1.3.1. внутреннее устройство
1.3.1.1. винтажные и журналируемые. зачем нужен журнал
1.3.1.2. плоские и иерархические
1.3.1.3. контроль доступа
1.3.2. POSIX
1.3.2.1. произвольное чтение
1.3.2.2. произвольная запись
1.3.2.3. атомарные операции
1.3.3. bells and whistles
1.3.3.1. сжатие, шифрование, дедупликация
1.3.3.2. snapshots
1.4. кеширование чтения и записи
2. HighLoad - это сеть
2.1. что вообще такое “HighLoad”, или “ведет ли кроилово к попадалову”
2.2. протоколы доступа: stateless и stateful
2.3. отказоустойчивость и ее двуличие
2.3.1. целостность данных
2.3.2. бесперебойные запись и чтение
2.4. Теорема CAP
3. Так в чем проблема?
3.1. Берем большую-пребольшую СХД и…
3.1.1. локальный кеш?!
3.1.2. конкурентная запись?!!
3.1.3. Берем OCFS2 и…
3.1.3.1. Как “падают виртуалки”?!
3.1.3.2. И почему так медленно?
3.1.4. А еще большую-пребольшую СХД довольно трудно получить в свое распоряжение
3.2. Берем CEPH/Lustre/LeoFS и…
3.2.1. Почему так медленно?!
3.2.2. Что значит “ребалансинг”?!
3.3. И немного о резервном копировании
3.3.1. Резервное копирование - это не отказоустойчивость
3.4. И снова про атомарные операции
3.5. Так почему все-таки нельзя просто сложить файлы в базу?
4. Что же делать?
4.1. В первую очередь это зависит от того, какова наша задача
4.1.1. А надо ли экономить?
4.1.2. POSIX - нужен ли он?
4.1.3. Большие файлы - нужны ли они?
4.1.4. Атомарные операции - нужны ли они?
4.1.5. Версионирование - нужно ли версионирование?
4.1.6. Насколько большим должно быть наше хранилище?
4.1.7. И собираемся ли мы удалять файлы?
4.1.8. И каков будет профиль нагрузки?
4.2. I’m feeling lucky - для некоторых сочет�
Как мы готовим MySQL / Николай Королёв (Badoo)Ontico
* Исторический экскурс, введение понятия спота, принцип функционального деления баз на группы (споты / не споты), шардирование как способ масштабирования спотов.
* Возникновение второго датацентра на другом континенте, создание самодельной репликации, позволяющей работать по схеме много -> много, краткая схема (структура спотов, схема репликации, служебные базы - очереди, репликация, мониторинг), плюсы и минусы этого решения, инструменты диагностики.
* Альтеры шадрированых спотов - первый вариант утилиты для этой задачи: схема его работы и возникшие проблемы; вторая версия утилиты - улучшения, а также, что осталось неисправленным.
* “Температура” спота, трудности её определения, проблемы, возникающие из-за его “перегрева”, наш способ решения и возникновение проекта “кладбище”.
* Деплой и около - почему мы используем MySQL в chroot, как мы его собираем и как деплоим.
* Бэкапы спотовых данных - первоначальное решение (ленточные хранилища), работа над ошибками, текущая схема.
* Query sampling: проект Minba.
Бинарные (файловые) хранилища- страшная сказка с мрачным концомDaniel Podolsky
1. Вводная часть: базовые понятия и определения
1.1. Что такое “файл”
1.2. Роль файлов в современном мире, миф о ненужности файлов
1.3. Файловое хранилище АКА файловая система
1.3.1. внутреннее устройство
1.3.1.1. винтажные и журналируемые. зачем нужен журнал
1.3.1.2. плоские и иерархические
1.3.1.3. контроль доступа
1.3.2. POSIX
1.3.2.1. произвольное чтение
1.3.2.2. произвольная запись
1.3.2.3. атомарные операции
1.3.3. bells and whistles
1.3.3.1. сжатие, шифрование, дедупликация
1.3.3.2. snapshots
1.4. кеширование чтения и записи
2. HighLoad - это сеть
2.1. что вообще такое “HighLoad”, или “ведет ли кроилово к попадалову”
2.2. протоколы доступа: stateless и stateful
2.3. отказоустойчивость и ее двуличие
2.3.1. целостность данных
2.3.2. бесперебойные запись и чтение
2.4. Теорема CAP
3. Так в чем проблема?
3.1. Берем большую-пребольшую СХД и…
3.1.1. локальный кеш?!
3.1.2. конкурентная запись?!!
3.1.3. Берем OCFS2 и…
3.1.3.1. Как “падают виртуалки”?!
3.1.3.2. И почему так медленно?
3.1.4. А еще большую-пребольшую СХД довольно трудно получить в свое распоряжение
3.2. Берем CEPH/Lustre/LeoFS и…
3.2.1. Почему так медленно?!
3.2.2. Что значит “ребалансинг”?!
3.3. И немного о резервном копировании
3.3.1. Резервное копирование - это не отказоустойчивость
3.4. И снова про атомарные операции
3.5. Так почему все-таки нельзя просто сложить файлы в базу?
4. Что же делать?
4.1. В первую очередь это зависит от того, какова наша задача
4.1.1. А надо ли экономить?
4.1.2. POSIX - нужен ли он?
4.1.3. Большие файлы - нужны ли они?
4.1.4. Атомарные операции - нужны ли они?
4.1.5. Версионирование - нужно ли версионирование?
4.1.6. Насколько большим должно быть наше хранилище?
4.1.7. И собираемся ли мы удалять файлы?
4.1.8. И каков будет профиль нагрузки?
4.2. I’m feeling lucky - для некоторых сочетаний требований решение есть!
4.3. А для остальных - решения нет.
5. Так что же все-таки делать? (заключение)
5.1. искать бюджет
5.2. все-таки сложить все файлы в базу - личное мнение докладчика
5.3. написать свое
5.3.1. не так это и сложно!
5.3.2. но все же довольно сложно
RTB DSP на языке Go укрощение buzzwords / Даниил Подольский (Qmobi.Com)Ontico
RTB и его проблематика должны быть знакомы участникам конференции — мало кто сегодня не слышал об этом способе получить много krps с жесткими ограничениями на время генерации ответа.
Вот и компания Qmobi решила поучаствовать в этой гонке и отхватить свой кусок пирога под названием “рынок мобильной рекламы”.
Анализ имеющихся вариантов показал, что Go должен прекрасно подойти для этой задачи. О том, на основании каких соображений мы сделали такой вывод, и какие из этих соображений прошли проверку практикой, а какие — нет, будет рассказано в докладе.
«Взломать за 60 секунд», Артем Кулаков, RedmadrobotMail.ru Group
Мобильные приложения плотно вошли в нашу жизнь, и с каждым годом их популярность растет. Приложениям доступно все больше информации о нас, и стоимость этой информации тоже повышается. Как и зачем взламывают приложения? Почему защита чаще всего оказывается неэффективной? Об этом пойдет речь в докладе.
Open source субд глазами обычного программистаSlach
Попытался "быстренько" пробежаться по всем СУБД с которыми работал за 20 лет и постараться вложить слушателям мысль что СУБД надо выбирать под нагрузку
и что для СУБД надо знать "алгоритмы" и "эксплуатацию"
Кэширование данных в web приложениях. Использование memcached / Юрий Красноще...Ontico
Каждый разработчик web приложений рано или поздно сталкивается с довольно типичной проблемой: перед ним стоит задача построить фабрику по производству омнониевых торсиометров.
Фабрика производит омнониевые торсиометры очень быстро, но для калибровки прибора (как известно) необходим омноний, за которым приходится летать на Андромеду.
Пока корабль летит до Андромеды, фабрика простаивает.
Самый очевидный выход из ситуации - построить склад омнониума прямо рядом с фабрикой.
Терминология кэширования
Выбор места для кэширования в WEB
Выбор данных для кэширования
Кэширование на стороне бэкенда
Отдельный кэширующий сервис
Пара слов о memcached
Пара слов о Redis
1. Вводная часть: базовые понятия и определения
1.1. Что такое “файл”
1.2. Роль файлов в современном мире, миф о ненужности файлов
1.3. Файловое хранилище АКА файловая система
1.3.1. внутреннее устройство
1.3.1.1. винтажные и журналируемые. зачем нужен журнал
1.3.1.2. плоские и иерархические
1.3.1.3. контроль доступа
1.3.2. POSIX
1.3.2.1. произвольное чтение
1.3.2.2. произвольная запись
1.3.2.3. атомарные операции
1.3.3. bells and whistles
1.3.3.1. сжатие, шифрование, дедупликация
1.3.3.2. snapshots
1.4. кеширование чтения и записи
2. HighLoad - это сеть
2.1. что вообще такое “HighLoad”, или “ведет ли кроилово к попадалову”
2.2. протоколы доступа: stateless и stateful
2.3. отказоустойчивость и ее двуличие
2.3.1. целостность данных
2.3.2. бесперебойные запись и чтение
2.4. Теорема CAP
3. Так в чем проблема?
3.1. Берем большую-пребольшую СХД и…
3.1.1. локальный кеш?!
3.1.2. конкурентная запись?!!
3.1.3. Берем OCFS2 и…
3.1.3.1. Как “падают виртуалки”?!
3.1.3.2. И почему так медленно?
3.1.4. А еще большую-пребольшую СХД довольно трудно получить в свое распоряжение
3.2. Берем CEPH/Lustre/LeoFS и…
3.2.1. Почему так медленно?!
3.2.2. Что значит “ребалансинг”?!
3.3. И немного о резервном копировании
3.3.1. Резервное копирование - это не отказоустойчивость
3.4. И снова про атомарные операции
3.5. Так почему все-таки нельзя просто сложить файлы в базу?
4. Что же делать?
4.1. В первую очередь это зависит от того, какова наша задача
4.1.1. А надо ли экономить?
4.1.2. POSIX - нужен ли он?
4.1.3. Большие файлы - нужны ли они?
4.1.4. Атомарные операции - нужны ли они?
4.1.5. Версионирование - нужно ли версионирование?
4.1.6. Насколько большим должно быть наше хранилище?
4.1.7. И собираемся ли мы удалять файлы?
4.1.8. И каков будет профиль нагрузки?
4.2. I’m feeling lucky - для некоторых сочет�
Как мы готовим MySQL / Николай Королёв (Badoo)Ontico
* Исторический экскурс, введение понятия спота, принцип функционального деления баз на группы (споты / не споты), шардирование как способ масштабирования спотов.
* Возникновение второго датацентра на другом континенте, создание самодельной репликации, позволяющей работать по схеме много -> много, краткая схема (структура спотов, схема репликации, служебные базы - очереди, репликация, мониторинг), плюсы и минусы этого решения, инструменты диагностики.
* Альтеры шадрированых спотов - первый вариант утилиты для этой задачи: схема его работы и возникшие проблемы; вторая версия утилиты - улучшения, а также, что осталось неисправленным.
* “Температура” спота, трудности её определения, проблемы, возникающие из-за его “перегрева”, наш способ решения и возникновение проекта “кладбище”.
* Деплой и около - почему мы используем MySQL в chroot, как мы его собираем и как деплоим.
* Бэкапы спотовых данных - первоначальное решение (ленточные хранилища), работа над ошибками, текущая схема.
* Query sampling: проект Minba.
Бинарные (файловые) хранилища- страшная сказка с мрачным концомDaniel Podolsky
1. Вводная часть: базовые понятия и определения
1.1. Что такое “файл”
1.2. Роль файлов в современном мире, миф о ненужности файлов
1.3. Файловое хранилище АКА файловая система
1.3.1. внутреннее устройство
1.3.1.1. винтажные и журналируемые. зачем нужен журнал
1.3.1.2. плоские и иерархические
1.3.1.3. контроль доступа
1.3.2. POSIX
1.3.2.1. произвольное чтение
1.3.2.2. произвольная запись
1.3.2.3. атомарные операции
1.3.3. bells and whistles
1.3.3.1. сжатие, шифрование, дедупликация
1.3.3.2. snapshots
1.4. кеширование чтения и записи
2. HighLoad - это сеть
2.1. что вообще такое “HighLoad”, или “ведет ли кроилово к попадалову”
2.2. протоколы доступа: stateless и stateful
2.3. отказоустойчивость и ее двуличие
2.3.1. целостность данных
2.3.2. бесперебойные запись и чтение
2.4. Теорема CAP
3. Так в чем проблема?
3.1. Берем большую-пребольшую СХД и…
3.1.1. локальный кеш?!
3.1.2. конкурентная запись?!!
3.1.3. Берем OCFS2 и…
3.1.3.1. Как “падают виртуалки”?!
3.1.3.2. И почему так медленно?
3.1.4. А еще большую-пребольшую СХД довольно трудно получить в свое распоряжение
3.2. Берем CEPH/Lustre/LeoFS и…
3.2.1. Почему так медленно?!
3.2.2. Что значит “ребалансинг”?!
3.3. И немного о резервном копировании
3.3.1. Резервное копирование - это не отказоустойчивость
3.4. И снова про атомарные операции
3.5. Так почему все-таки нельзя просто сложить файлы в базу?
4. Что же делать?
4.1. В первую очередь это зависит от того, какова наша задача
4.1.1. А надо ли экономить?
4.1.2. POSIX - нужен ли он?
4.1.3. Большие файлы - нужны ли они?
4.1.4. Атомарные операции - нужны ли они?
4.1.5. Версионирование - нужно ли версионирование?
4.1.6. Насколько большим должно быть наше хранилище?
4.1.7. И собираемся ли мы удалять файлы?
4.1.8. И каков будет профиль нагрузки?
4.2. I’m feeling lucky - для некоторых сочетаний требований решение есть!
4.3. А для остальных - решения нет.
5. Так что же все-таки делать? (заключение)
5.1. искать бюджет
5.2. все-таки сложить все файлы в базу - личное мнение докладчика
5.3. написать свое
5.3.1. не так это и сложно!
5.3.2. но все же довольно сложно
RTB DSP на языке Go укрощение buzzwords / Даниил Подольский (Qmobi.Com)Ontico
RTB и его проблематика должны быть знакомы участникам конференции — мало кто сегодня не слышал об этом способе получить много krps с жесткими ограничениями на время генерации ответа.
Вот и компания Qmobi решила поучаствовать в этой гонке и отхватить свой кусок пирога под названием “рынок мобильной рекламы”.
Анализ имеющихся вариантов показал, что Go должен прекрасно подойти для этой задачи. О том, на основании каких соображений мы сделали такой вывод, и какие из этих соображений прошли проверку практикой, а какие — нет, будет рассказано в докладе.
«Взломать за 60 секунд», Артем Кулаков, RedmadrobotMail.ru Group
Мобильные приложения плотно вошли в нашу жизнь, и с каждым годом их популярность растет. Приложениям доступно все больше информации о нас, и стоимость этой информации тоже повышается. Как и зачем взламывают приложения? Почему защита чаще всего оказывается неэффективной? Об этом пойдет речь в докладе.
Доклад от Parallels:
Методики тестировния производительности database-centric приложений
Описание: При работе над сложными продуктами в database-centric приложениях изменения в коде и тем более в SQL запросах к базе данных могут приводить к неожиданным падениям производительности или же деградации производительности приложения с ростом размера базы данных. Поэтому важно уметь как можно быстрее отлавливать и исправлять причины таких деградаций.
Доклад о том, как устроен процесс мониторинга производительности продукта автоматизации хостинга и облачных сервисов Parallels Automation, для которого определяющим фактором является производительность базы данных.
Компания покажет, как анализирует планы исполнения SQL запросов внутри PostgreSQL, как проверяет насколько быстро и эффективно в целом работают SQL запросы, как определяет стратегию дальнейшей оптимизации.
2. ПРИВЕТ
О чем буду рассказывать?
Меня зовут Макс Лапшин
•max@maxidoors.ru
•http://github.com/maxlapshin
•модератор ror2ru
3. ПРОБЛЕМЫ КЕШИРОВАНИЯ
Это точно кому-то нужно?
Кеширование — сохранение однажды
вычисленных данных для последующего их
повторного использования.
Кеширование затрагивает следующие проблемы:
•запись кешируемых данных;
•извлечение закешированных данных;
•очистка неактуальных закешированных данных,
т.е. поддержание когерентности кеша
Последний пункт, пожалуй, самый проблемный.
4. ЗАЧЕМ КЕШИРОВАТЬ?
А чего кешировать?
•Быстрый рендеринг одной страницы даже на
малопосещаемом сайте
•Приемлемая загрузка при большом потоке
посетителей
•Быстрые апдейты
•Быстрые выборки
•Быстрый рендеринг
5. КАНДИДАТЫ В КЕШ
Да ну, чего там медленного?
Примеры с живых сайтов:
•Счетчик непрочитанных сообщений;
•Корреспонденты по переписке в личных
сообщениях на lookatme.ru;
•Сложно сгруппированные атрибуты из 4-
табличного JOIN-а в спецификации камеры на
new.prophotos.ru
6. ОТКУДА НАГРУЗКА?
При выборке списка корреспондентов из таблицы
сообщений происходит JOIN и группировка
таблиц больше 1M записей. Это чудовищная
нагрузка на любую базу.
При показе счетчика сообщений происходит
выборка из огромной таблицы на каждом показе
страницы.
Это неоправданная нагрузка на базу и замедление
отдачи страницы.
7. МОЖЕТ MEMCACHED?
Чем же плох memcached?
Очень быстрая сетевая, прекрасно
масштабирующаяся, хеш-таблица с
гарантированным максимальным временем жизни
записи и гарантированным отсутствием гарантий
жизни чего-бы то ни было.
Он вообще имеет право ничего не сохранять.
8. ЧЕМ ПЛОХ MEMCACHED?
А куда кешировать?
МНОГИМ
•Нельзя получить список ключей;
•Нет100% гарантии когерентности кеша;
•Данные из Memcached нельзя использовать в
SQL выборках;
•Его надо разогревать;
•Не решает проблему медленного показа редко
посещаемых страниц.
9. НЕУЖЕЛИ ВСЁ ТАКИ В БД?
А подетальнее?
•Счетчик непрочитанных сообщений в переписке
между двумя пользователями будет
использоваться при рендеринге раздела
«непрочитанные». Использовать memcached
невозможно.
•Сохранить в событие список идущих на него
user_id, сохранить пользователю список friends_id
и можно прям в БД получить количество идущих
на событие друзей.
10. СТРАТЕГИИ КЕШИРОВАНИЯ
А подетальнее?
•Со счетчиками всё ясно: их стоит кешировать
всегда. @user.friends.count @user.friends.size
•Кеширование может породить целую модель,
решающую проблему кеша. Например
«Переписка», в ней будут храниться все данные
для быстрого рендеринга: user_login, sender_login,
last_message_id;
•Специфичные средства БД (PostgreSQL).
11. СЧЕТЧИКИ
А чего со списком друзей?
•Всегда делайте NOT NULL DEFAULT 0;
•Лучше инкрементить/декрементить из
after_create/after_destroy дочерней модели;
•Если не лочить таблицу, то возможны коллизии,
надо быть готовым всегда пересчитать сбившийся
счетчик (-5 непрочитанных сообщений);
•Всегда использовать @user.friends.size, потому
что он использует @user.friends_count
12. СПИСКИ
•Rails (без патчей) не позволяют иметь свой
формат сериализуемого атрибута, поэтому если
сохранять через serialize, в базе будетYAML. Это
большой overhead;
•Нет ничего страшного в том, что бы
сгенерироватьYAML SQL-запросом, это может
быть в 200 раз быстрее, чем через find_each и save;
•В PostgreSQL есть тип ARRAY, который можно
заполнять, пересекать и обрабатывать прям в базе:
13. СЛОЖНЫЕ ДАННЫЕ
Что ещё за композитные типы?
•При показе спецификации фотоаппарата, надо
вытянуть список свойств камеры, список типов
свойств и по нему сгруппировать свойства;
•Если у вас Mysql, то делайте всё в рельсах,
сохраняйте группированные данные вYAML. Это
медленно, но другого способа нет. На обработку
5000 записей уходит до получаса.
•В PostgreSQL есть композитные типы —
палочка-выручалочка.
14. КОМПОЗИТНЫЕ ТИПЫ
Как с таким нонконформизмом работать?
На new.prophotos.ru была опробована методика
сохранения группированных данных
специфичными средствами БД:
15. WRITE ONCE
А кто это будет читать?
Такие данные можно только переписывать и
читать. Дописывать в такую колонку
нецелесообразно. Апдейт всей таблицы 30 сек
16. READ FAST
Просто так рельсы не умеют читать композитные
типы и массивы:
{"(vendor_text,{Cavei},string,Производитель)","(name,"{""CV-PT10 H3""}",string,Модель)","(type,
{настольный},string,Тип)","(purpose,"{""фото- и видеокамеры""}",string,"Сфера применения")","(construction,
{трипод},string,Конструкция)",…
Для этого был написан неопубликованный патч
PostgresParser:
>> Device.find_by_permalink('pentax-k10d').cached_properties
=> [#<struct ArrayRetrieval::CachedProperty name="fullname", values=["Pentax K10D"], data_format="string",
description="Полное название">, #<struct ArrayRetrieval::CachedProperty name="start_date", values=["2006/09/13"],
data_format="string", description="Дата анонса">, #<struct ArrayRetrieval::CachedProperty name="lens_mount", values=["KAF"],
data_format="string", description="Байонет">
Код ещё медленный, по 20 мс на разбор 120
свойств в текстовом виде вместо 200-300 мс на
вытаскивание из БД.
ActiveRecord внутри — жуть =(
И помогло?
17. РЕЗУЛЬТАТЫ
Лично я стараюсь сейчас придерживаться такой
стратегии: кешировать в базе данные, которые
можно вычислить.
В memcached класть только HTML, который не
требует быть 100% синхронным. Я пока не нашел
разумного способа отслеживать зависимости
фрагментов в мемкеше от данных.
Кеширование в базе разумно делать с помощью
расширенных средств БД, т.к. кеш штука
опциональная.
И помогло?