Хранение данных на виниле / Константин Осипов (tarantool.org)Ontico
В rfc1149 дан исчерпывающий обзор преимуществ голубиной почты для протокола IP: низкая пропускная способность, невысокая надёжность, простая топология сети. Для того чтобы дать адекватный ответ вызовам эпохи мемристоров и квантовых вычислений, Tarantool 1.7 содержит новый движок для хранения данных на классических жёстких дисках и флэш-накопителях: Vinyl. Tarantool известен своей скоростью, и мы постарались не ударить в грязь лицом и на этот раз.
В докладе я расскажу об устройстве нашего нового storage engine:
- как мы объединили in-memory технологию и LSM (log structured merge) деревья для достижения оптимальной производительности и утилизации ресурса накопителя,
- как работает multiversion concurrency control в Vinyl,
- основной компонент в промышленной реализации LSM дерева - merge scheduler, т.е. планировщик слияний и сборки мусора дерева. Я расскажу о подходе, который позволяет максимально снизить износ накопителя, при этом уложиться в заданные рамки производительности запросов.
Flashcache в mamba.ru / Яковлев Александр Юрьевич (ЗАО Мамба)Ontico
Некоторое время назад, когда в очередной раз встал вопрос о производительности большого парка mysql sharding серверов, мы не захотели покупать новые сервера и производить resharding. Мы обнаружили, что компания facebook выпустила в opensource большое количество своих разработок, в том числе и модуль ядра flashcache.
Flashcache — модуль для кэширования блоков блочного устройства, предоставляющий 4 разных режима кэширования.
В данном докладе я расскажу, как мы тестировали, поэтапно проверяя под нагрузкой, 3 из 4 режимов кэширования, сравнивая и выбирая оптимальный. Итогом данной работы стало внедрение данного модуля в нашу архитектуру (фотосервера, сервера БД).
Защита данных и датацентров от катастроф. Подход Nutanix / Максим Шапошников ...Ontico
+ Защита данных — это не "одна кнопка", нет годного любому единого решения. Задача всегда диктует выбор средств и решений.
+ RTO — Recovery Time Objective — максимальное время, за которое все ваши бизнес-задачи должны полностью быть восстановлены в работоспособное состояние после полной катастрофы ДЦ.
+ RPO — Recovery Point Objective — максимально приемлемый для ваших задач промежуток времени, за который вы готовы потерять данные.
+ Защита на уровне приложений. Приложение лучше всех знает, как защищать и реплицировать свои данные.
+ Асинхронная репликация — наилучший выход с точки зрения производительности, единственно возможный вариант в случае значительного географического разнесения дата-центров (сотни и более километров). Работает на уровне виртуальных машин.
+ Метро / "растянутые" кластеры и синхронная репликация — нулевой RPO, минимальный RTO, большие потери производительности и множество ограничений. Но иногда — единственный выход, если уровень приложения не умеет реплицировать данные.
+ Лучший подход — комбинация из репликации на уровне приложений, асинхронной и синхронной репликации средствами хранилища.
+ Что есть у Nutanix для решения подобных задач: DR (Async replication), Metro availability cluster, Timestream Backup.
+ Реализация решения с использованием Nutanix на примере FBI: крупнейший VDI в США. Защищенная, mission-critical инфраструктура на 70 тысяч виртуальных десктопов. Асинхронная репликация дата-центров на 1500 миль, защита данных от катастроф.
Хранение данных на виниле / Константин Осипов (tarantool.org)Ontico
В rfc1149 дан исчерпывающий обзор преимуществ голубиной почты для протокола IP: низкая пропускная способность, невысокая надёжность, простая топология сети. Для того чтобы дать адекватный ответ вызовам эпохи мемристоров и квантовых вычислений, Tarantool 1.7 содержит новый движок для хранения данных на классических жёстких дисках и флэш-накопителях: Vinyl. Tarantool известен своей скоростью, и мы постарались не ударить в грязь лицом и на этот раз.
В докладе я расскажу об устройстве нашего нового storage engine:
- как мы объединили in-memory технологию и LSM (log structured merge) деревья для достижения оптимальной производительности и утилизации ресурса накопителя,
- как работает multiversion concurrency control в Vinyl,
- основной компонент в промышленной реализации LSM дерева - merge scheduler, т.е. планировщик слияний и сборки мусора дерева. Я расскажу о подходе, который позволяет максимально снизить износ накопителя, при этом уложиться в заданные рамки производительности запросов.
Flashcache в mamba.ru / Яковлев Александр Юрьевич (ЗАО Мамба)Ontico
Некоторое время назад, когда в очередной раз встал вопрос о производительности большого парка mysql sharding серверов, мы не захотели покупать новые сервера и производить resharding. Мы обнаружили, что компания facebook выпустила в opensource большое количество своих разработок, в том числе и модуль ядра flashcache.
Flashcache — модуль для кэширования блоков блочного устройства, предоставляющий 4 разных режима кэширования.
В данном докладе я расскажу, как мы тестировали, поэтапно проверяя под нагрузкой, 3 из 4 режимов кэширования, сравнивая и выбирая оптимальный. Итогом данной работы стало внедрение данного модуля в нашу архитектуру (фотосервера, сервера БД).
Защита данных и датацентров от катастроф. Подход Nutanix / Максим Шапошников ...Ontico
+ Защита данных — это не "одна кнопка", нет годного любому единого решения. Задача всегда диктует выбор средств и решений.
+ RTO — Recovery Time Objective — максимальное время, за которое все ваши бизнес-задачи должны полностью быть восстановлены в работоспособное состояние после полной катастрофы ДЦ.
+ RPO — Recovery Point Objective — максимально приемлемый для ваших задач промежуток времени, за который вы готовы потерять данные.
+ Защита на уровне приложений. Приложение лучше всех знает, как защищать и реплицировать свои данные.
+ Асинхронная репликация — наилучший выход с точки зрения производительности, единственно возможный вариант в случае значительного географического разнесения дата-центров (сотни и более километров). Работает на уровне виртуальных машин.
+ Метро / "растянутые" кластеры и синхронная репликация — нулевой RPO, минимальный RTO, большие потери производительности и множество ограничений. Но иногда — единственный выход, если уровень приложения не умеет реплицировать данные.
+ Лучший подход — комбинация из репликации на уровне приложений, асинхронной и синхронной репликации средствами хранилища.
+ Что есть у Nutanix для решения подобных задач: DR (Async replication), Metro availability cluster, Timestream Backup.
+ Реализация решения с использованием Nutanix на примере FBI: крупнейший VDI в США. Защищенная, mission-critical инфраструктура на 70 тысяч виртуальных десктопов. Асинхронная репликация дата-центров на 1500 миль, защита данных от катастроф.
Контейнерная виртуализация. Золушка в облакахrusonyx
Слайды доклада с конференции Российские Интернет Технологии 2013 http://ritconf.ru
Для обеспечения работы крупных веб-проектов как правило реализуются два сценария: железный и облачный.
Классический железный сценарий предполагает решение задачи в лоб и чреват серьезными осложнениями в дальнейшем.
Более модный облачный вариант выбирают все чаще. В этом случае речь идет о построении инфраструктурного облака с использованием гипервизора: полной виртуализации (как правило, VMware), либо паравиртуализации (как правило, XEN).
В докладе предлагается третий сценарий развития веб-проектов: построение облака с использованием контейнерной виртуализации Parallels Virtuozzo Containers (виртуализация на базе операционной системы) на примере Русоникса. Опыт Русоникса - это тысячи виртуальных серверов для тысяч разноплановых веб-проектов с заведомо непредсказуемым поведением на базе контейнерной виртуализации и типового железа.
Контейнеры обеспечивают невероятную плотность и эффективность использования физических ресурсов. Технология используется, например, в Google для выполнения важнейших задач, таких как вывод результатов поиска и показ контекстных объявлений. Однако, несмотря на все преимущества, контейнерная виртуализация остается в тени и на практике известна не так широко, как VMware в корпоративном мире или XEN в облачно-амазонном.
Ceph является одной из мнообещающих архитектур для построения облачных хранилищ данных. В презентации приведены основные возможности, описана архитектура, дан краткий обзор команд CLI
Chronicle Map — key-value хранилище для трейдинга на Java / Левентов Роман (C...Ontico
Сфера финансовых приложений и трейдинга выдвигает особые требования к системам обработки данных: ультракороткие задержки, конкурентные обновления (в т.ч. из разных процессов), репликация высокочастотных обновлений.
Существовавшие открытые key-value хранилища не справлялись, поэтому мы сделали свое — Chronicle Map.
В докладе я отвечу на вопросы:
+ Почему бывает эффективнее разбить систему, работающую с общим состоянием, на несколько отдельных процессов?
+ Зачем вам может захотеться распилить JVM на несколько частей?
+ Как добиться от key-value хранилища медианной latency меньше 1 микросекунды?
+ Как сделать репликацию, если она упирается в пропускную способность сети из-за слишком частых обновлений?
Развею миф о том, что Java — это медленно :)
Также, в докладе будет сравнение Chronicle Map с redis, one-nio и ConcurrentHashMap.
Что особенного в СУБД для данных в оперативной памяти / Константин Осипов (Ta...Ontico
Оперативная память становится всё более дешёвой и производительной, что позволяет использовать её для хранения рабочего набора данных всё большего числа приложений. Хранение всех данных в оперативной памяти позволяет сделать их высоко доступными, а алгоритмы для работы с данными либо существенно упростить, либо ускорить, а иногда — и то, и другое.
Тезисы - http://www.highload.ru/2015/abstracts/1964.html
Тюним память и сетевой стек в Linux: история перевода высоконагруженных серве...Ontico
В процессе обновления высоконагруженных серверов раздачи видео (40Gbit/s с каждого сервера) со старого OpenSuSE 10.2 на новый CentOS 7 (время между релизами — 7 лет) мы столкнулись с рядом проблем — необъяснимый свопинг и запуски OOM killer, неравномерное распределение нагрузки по ядрам, обрывы соединений, скачки системной нагрузки на CPU.
В докладе будет рассказано о том, как мы боролись с этими проблемами и какие технологии для этого использовали.
Андрей Николаенко, IBS. NVMf: 5 млн IOPS по сети своими рукамиIBS
Андрей Николаенко, системный архитектор в IBS, выступил на конференции HighLoad++ 2016.
Тезисы
В выпуске 4.8 ядра Linux появилась поддержка NVMf (NVM Express over Fabrics) — стандартизованной возможности присоединять по сети как блочные устройства твердотельные накопители, установленные в разъёмы PCI Express. NVMf лишён многих недостатков iSCSI, повторяющего по сети SCSI-команды со всеми их издержками времён дисковых накопителей, и главное — позволяет по полной использовать возможности сетей с прямым доступом к оперативной памяти (RDMA). Таким образом, можно под управлением одного узла собрать сверхбыстрый и сверхотзывчивый пул блочных устройств, не прибегая к покупке дорогого флэш-массива. Но как воспользоваться этим пулом, не загубив теоретические показатели программными обёртками?
В докладе будут рассмотрены варианты применения NVMf для различных конфигураций PostgreSQL, Oracle Database, Hadoop, файловых хранилищ, о разработках в направлении «программно-определяемой памяти» с применением NVMe-устройств, доступных по сети, обсуждены текущие проблемы, ограничения и перспективы. Особое внимание будет уделено практическим способам измерения производительности ввода-вывода с учётом задачи, решаемой подсистемой хранения.
Эволюция программно-аппаратного обеспечения хранения фотографий в Badoo / Дми...Ontico
На примере нашей системы хранения фотографий мы хотим рассказать о проблемах, с которыми столкнулись в течение прошедших семи лет, связанных с ее программными и аппаратными компонентами, и о путях их решений.
В данном докладе речь пойдет о том, как сохранить независимость от поставщика и построить масштабируемую систему хранения с длительным сроком эксплуатации и способностью к оперативному внесению изменений в конфигурацию. Как сделать изменения на аппаратном уровне прозрачными для разработчиков, а также о том, как упростить развертывание и обслуживание.
В общих чертах изложен опыт и проблемы, которые мы получили в ходе эксплуатации классических мультиконтроллерных СХД. Основная тема - построение собственных хранилищ на базе общедоступных компонентов (полки, адаптеры, экспандеры, интерпозеры, диски, ЦПУ и т.д.) с потенциальной возможностью замены любого из выше перечисленного на другую модель. Дублирование критически важных узлов в рамках одной СХД. Обзор используемых транспортов - SRP, FC, iSCSI и описание того, каким образом можно быстро адаптировать такое хранилище под один или несколько транспортов, с минимальными вложениями. Обзор ПО для реализации СХД (SCST/LIO или проприетарные решения в области Software Defined Storage ). Автоматизация развертывания (инсталляция/управление с помощью Puppet). Тестирование перед вводом в эксплуатацию. Multipath I/O и упрощение именования экспортируемых блочных устройств. Политика составления наборов firmware для стабильной работы. Мониторинг. Расследование сбоев (Order of failure и т.п.).
Движок LMDB — особенный чемпион / Юрьев Леонид (Петер-Сервис R&D)Ontico
Lightning Memory-Mapped Database (LMDB) представляет собой интересный, во многом уникальный движок базы данных класса Berkeley DB и Level DB с ребус-подобным исходным кодом. Будучи относительно малоизвестным, LMDB показывает ЧЕМПИОНСКУЮ производительность по чтению. Однако при интенсивной записи всё не так радужно…
Было ещё несколько проблем и недостатков, которые нам пришлось устранить, разбираясь в ребусах исходного кода. Доклад точно будет интересен разработчикам, интересующимся внутренностями баз данных или характеристиками отдельных движков.
Проект реализуется силами компании Петер-Сервис R&D, резидента Сколково, для применения в телеком-проектах федерального масштаба.
Информация о нашем проекте https://github.com/ReOpen/ReOpenLDAP/wiki, об исходной версии LMDB http://symas.com/mdb/.
LinuxCon 2011: OpenVZ and Linux Kernel TestingAndrey Vagin
I'm curious. For the past few months, people@openvz.org have discovered (and fixed) an ongoing stream of obscure but serious and quite long-standing bugs.
How are you discovering these bugs?
Andrew added later:
hm, OK, I was visualizing some mysterious Russian bugfinding machine or something.
Don't stop ;)
Containers are typically managed by having each container chroot to its own subdirectory of the host filesystem. This leads to problems like journal bottlenecks and inefficient small file I/O. The proposed solution is to manage each container's filesystem within a virtual block device represented by a file (container-in-a-file). This avoids journal bottlenecks and allows efficient operations like backup, migration and snapshots through copy-on-write images. It provides flexibility in filesystem choice and management while solving storage and I/O issues. Future work includes optimizing the design and integrating it into the Linux kernel.
Контейнерная виртуализация. Золушка в облакахrusonyx
Слайды доклада с конференции Российские Интернет Технологии 2013 http://ritconf.ru
Для обеспечения работы крупных веб-проектов как правило реализуются два сценария: железный и облачный.
Классический железный сценарий предполагает решение задачи в лоб и чреват серьезными осложнениями в дальнейшем.
Более модный облачный вариант выбирают все чаще. В этом случае речь идет о построении инфраструктурного облака с использованием гипервизора: полной виртуализации (как правило, VMware), либо паравиртуализации (как правило, XEN).
В докладе предлагается третий сценарий развития веб-проектов: построение облака с использованием контейнерной виртуализации Parallels Virtuozzo Containers (виртуализация на базе операционной системы) на примере Русоникса. Опыт Русоникса - это тысячи виртуальных серверов для тысяч разноплановых веб-проектов с заведомо непредсказуемым поведением на базе контейнерной виртуализации и типового железа.
Контейнеры обеспечивают невероятную плотность и эффективность использования физических ресурсов. Технология используется, например, в Google для выполнения важнейших задач, таких как вывод результатов поиска и показ контекстных объявлений. Однако, несмотря на все преимущества, контейнерная виртуализация остается в тени и на практике известна не так широко, как VMware в корпоративном мире или XEN в облачно-амазонном.
Ceph является одной из мнообещающих архитектур для построения облачных хранилищ данных. В презентации приведены основные возможности, описана архитектура, дан краткий обзор команд CLI
Chronicle Map — key-value хранилище для трейдинга на Java / Левентов Роман (C...Ontico
Сфера финансовых приложений и трейдинга выдвигает особые требования к системам обработки данных: ультракороткие задержки, конкурентные обновления (в т.ч. из разных процессов), репликация высокочастотных обновлений.
Существовавшие открытые key-value хранилища не справлялись, поэтому мы сделали свое — Chronicle Map.
В докладе я отвечу на вопросы:
+ Почему бывает эффективнее разбить систему, работающую с общим состоянием, на несколько отдельных процессов?
+ Зачем вам может захотеться распилить JVM на несколько частей?
+ Как добиться от key-value хранилища медианной latency меньше 1 микросекунды?
+ Как сделать репликацию, если она упирается в пропускную способность сети из-за слишком частых обновлений?
Развею миф о том, что Java — это медленно :)
Также, в докладе будет сравнение Chronicle Map с redis, one-nio и ConcurrentHashMap.
Что особенного в СУБД для данных в оперативной памяти / Константин Осипов (Ta...Ontico
Оперативная память становится всё более дешёвой и производительной, что позволяет использовать её для хранения рабочего набора данных всё большего числа приложений. Хранение всех данных в оперативной памяти позволяет сделать их высоко доступными, а алгоритмы для работы с данными либо существенно упростить, либо ускорить, а иногда — и то, и другое.
Тезисы - http://www.highload.ru/2015/abstracts/1964.html
Тюним память и сетевой стек в Linux: история перевода высоконагруженных серве...Ontico
В процессе обновления высоконагруженных серверов раздачи видео (40Gbit/s с каждого сервера) со старого OpenSuSE 10.2 на новый CentOS 7 (время между релизами — 7 лет) мы столкнулись с рядом проблем — необъяснимый свопинг и запуски OOM killer, неравномерное распределение нагрузки по ядрам, обрывы соединений, скачки системной нагрузки на CPU.
В докладе будет рассказано о том, как мы боролись с этими проблемами и какие технологии для этого использовали.
Андрей Николаенко, IBS. NVMf: 5 млн IOPS по сети своими рукамиIBS
Андрей Николаенко, системный архитектор в IBS, выступил на конференции HighLoad++ 2016.
Тезисы
В выпуске 4.8 ядра Linux появилась поддержка NVMf (NVM Express over Fabrics) — стандартизованной возможности присоединять по сети как блочные устройства твердотельные накопители, установленные в разъёмы PCI Express. NVMf лишён многих недостатков iSCSI, повторяющего по сети SCSI-команды со всеми их издержками времён дисковых накопителей, и главное — позволяет по полной использовать возможности сетей с прямым доступом к оперативной памяти (RDMA). Таким образом, можно под управлением одного узла собрать сверхбыстрый и сверхотзывчивый пул блочных устройств, не прибегая к покупке дорогого флэш-массива. Но как воспользоваться этим пулом, не загубив теоретические показатели программными обёртками?
В докладе будут рассмотрены варианты применения NVMf для различных конфигураций PostgreSQL, Oracle Database, Hadoop, файловых хранилищ, о разработках в направлении «программно-определяемой памяти» с применением NVMe-устройств, доступных по сети, обсуждены текущие проблемы, ограничения и перспективы. Особое внимание будет уделено практическим способам измерения производительности ввода-вывода с учётом задачи, решаемой подсистемой хранения.
Эволюция программно-аппаратного обеспечения хранения фотографий в Badoo / Дми...Ontico
На примере нашей системы хранения фотографий мы хотим рассказать о проблемах, с которыми столкнулись в течение прошедших семи лет, связанных с ее программными и аппаратными компонентами, и о путях их решений.
В данном докладе речь пойдет о том, как сохранить независимость от поставщика и построить масштабируемую систему хранения с длительным сроком эксплуатации и способностью к оперативному внесению изменений в конфигурацию. Как сделать изменения на аппаратном уровне прозрачными для разработчиков, а также о том, как упростить развертывание и обслуживание.
В общих чертах изложен опыт и проблемы, которые мы получили в ходе эксплуатации классических мультиконтроллерных СХД. Основная тема - построение собственных хранилищ на базе общедоступных компонентов (полки, адаптеры, экспандеры, интерпозеры, диски, ЦПУ и т.д.) с потенциальной возможностью замены любого из выше перечисленного на другую модель. Дублирование критически важных узлов в рамках одной СХД. Обзор используемых транспортов - SRP, FC, iSCSI и описание того, каким образом можно быстро адаптировать такое хранилище под один или несколько транспортов, с минимальными вложениями. Обзор ПО для реализации СХД (SCST/LIO или проприетарные решения в области Software Defined Storage ). Автоматизация развертывания (инсталляция/управление с помощью Puppet). Тестирование перед вводом в эксплуатацию. Multipath I/O и упрощение именования экспортируемых блочных устройств. Политика составления наборов firmware для стабильной работы. Мониторинг. Расследование сбоев (Order of failure и т.п.).
Движок LMDB — особенный чемпион / Юрьев Леонид (Петер-Сервис R&D)Ontico
Lightning Memory-Mapped Database (LMDB) представляет собой интересный, во многом уникальный движок базы данных класса Berkeley DB и Level DB с ребус-подобным исходным кодом. Будучи относительно малоизвестным, LMDB показывает ЧЕМПИОНСКУЮ производительность по чтению. Однако при интенсивной записи всё не так радужно…
Было ещё несколько проблем и недостатков, которые нам пришлось устранить, разбираясь в ребусах исходного кода. Доклад точно будет интересен разработчикам, интересующимся внутренностями баз данных или характеристиками отдельных движков.
Проект реализуется силами компании Петер-Сервис R&D, резидента Сколково, для применения в телеком-проектах федерального масштаба.
Информация о нашем проекте https://github.com/ReOpen/ReOpenLDAP/wiki, об исходной версии LMDB http://symas.com/mdb/.
LinuxCon 2011: OpenVZ and Linux Kernel TestingAndrey Vagin
I'm curious. For the past few months, people@openvz.org have discovered (and fixed) an ongoing stream of obscure but serious and quite long-standing bugs.
How are you discovering these bugs?
Andrew added later:
hm, OK, I was visualizing some mysterious Russian bugfinding machine or something.
Don't stop ;)
Containers are typically managed by having each container chroot to its own subdirectory of the host filesystem. This leads to problems like journal bottlenecks and inefficient small file I/O. The proposed solution is to manage each container's filesystem within a virtual block device represented by a file (container-in-a-file). This avoids journal bottlenecks and allows efficient operations like backup, migration and snapshots through copy-on-write images. It provides flexibility in filesystem choice and management while solving storage and I/O issues. Future work includes optimizing the design and integrating it into the Linux kernel.
Автоматическая оптимизация алгоритмов с помощью быстрого возведения матриц в ...Alexander Borzunov
Описание декоратора для автоматической оптимизации алгоритмов с помощью быстрого возведения матриц в степень в Python.
Смотрите подробнее:
GitHub: https://github.com/borzunov/cpmoptimize
Хабрахабр: http://habrahabr.ru/post/236689/
Python Package Index: https://pypi.python.org/pypi/cpmoptimize
Доклад на конференции Bitcoin Conference Russia 2015 о новом типе фьючерсного контракта, который оказался очень удачным для биткойн-трейдеров.
Видео доклада, включая самое интересное - вопросы и ответы, смотрите на YouTube: https://youtu.be/2iCljuZWvdE
HaltDos is a high throughput, high performance software based network appliance that can stay updated with evolving technology and threats without requiring hardware replacements. With its multi-layered and multi-vector approach, it can defend against a wide range of DDoS attacks within seconds to ensure high uptime of your website/web services.
Каждый разработчик рано или поздно сталкивается с предметно-ориентированными языками (DSL). Мы разберемся, зачем же нам нужны DSL, и какие проблемы они нам помогают решать. Поймем, в каких случаях нам стоит разрабатывать свой язык, а в каких — использовать уже существующий. Попробуем провести грань и решить, где у нас просто библиотека, а где — предметно ориентированный язык. Придумаем свой DSL и сравним различные подходы к работе с ним в Python. Увидим, как работают лексический и синтаксический анализаторы. Обязательно поговорим про то, как облегчить жизнь пользователям нашего языка. Как сделать информативными сообщения об ошибках? Как тестировать сценарии, написанные на нашем языке? На эти вопросы мы сможем дать ответ.
Электронная коммерция: от Hadoop к Spark ScalaRoman Zykov
Как обрабатывать большой объем данных быстро с наименьшими затратами? Мы смогли этого добиться в компании
RetailRocket. Обработка данных – это наш бизнес! У нас много данных: более 100 Тбайт, в сутки нам поступает более 100 млн
событий для обработки. До недавнего времени у нас все работало на кластере на базе Hadoop относительно устаревшего
дистрибутива Cloudera CDH 4.5, программный код был написан на Pig, Hive, Python и Java. Это порождало ряд проблем с
архитектурой, производительностью. Тестирование превращалось в настоящую головную боль. В конце лета RetailRocket
перешел на Yarn на базе CDH 5.1.2. Это открыло путь к более совершенным технологиям семейства Spark. Сейчас мы
находимся в фазе полного перехода на Spark на функциональном языке Scala. Это позволило нам избавиться от зоопарка
технологий, упростив архитектуру решений и автоматизировав тестирование. Первые результаты не заставили себя ждать –
получен прирост производительности на том же железе в три-пять раз. А это значит, что мы будем меньше инвестировать в
расширение парка серверов кластера. В докладе будет рассказано о проблемах, с которыми мы столкнулись, и о том как мы
их решили. Будут примеры исходного кода для оптимизации производительности и повышения удобства работы, который мы
закоммитили в наш публичный GitHub
Value Objects, Full Throttle (to be updated for spring TC39 meetings)Brendan Eich
Slides I prepared for the 29 January 2014 Ecma TC39 meeting, on Value Objects in JS, an ES7 proposal -- this one shotgunned the roadmap-space of declarative syntax, to find the right amount per TC39 (nearly zero, turns out).
The document discusses issues with Scala and how programming is currently done. It argues that programming languages try to do too much with general purpose tools that are not well-suited for many tasks. This leads to bugs, poor performance, and lack of modifiability. The author advocates restricting languages and tools to specific domains and ensuring interfaces between components are well-defined and opaque. The goal is to have tools that focus on correctness, understand code changes instantly, and help programmers rather than simulate computing on their own.
Optimising Your Front End Workflow With Symfony, Twig, Bower and GulpMatthew Davis
We take great care in our back end coding workflow, optimising, automating and abstracting as much as is possible. So why don't we do that with our front end code?
We'll take a look at some tools to help us take our front end workflow to the next level, and hopefully optimise our load times in the process!
We'll be looking at using Twig templates and optimising them for the different areas of your application, integrating Bower and Gulp for managing assets and processing our front-end code to avoid repetitive tasks - looking at how that impacts the typical Symfony workflow.
Франкенштейнизация Voldemort или key-value данные в Одноклассниках. Роман Ан...odnoklassniki.ru
A talk from jokerconf.com conference.
"Frankenstaining of Voldemort" or "key-value storage evolution at Odnoklassniki"
В докладе освещены Java-технологии хранения данных, обслуживающие десятки миллионов пользователей и работающие на сотнях серверов.
На примере социальной сети "Одноклассники" мы рассмотрим эволюцию хранилищ данных с высоким уровнем конкурентного доступа и с соблюдением требования постоянной доступности.
Мы разберём сильные и слабые стороны каждого из решений, начиная от технологии master-slave репликации на основе Berkeley DB и заканчивая симбиозом распределенных хранилищ Voldemort и Cassandra.
Технологии хранения для больших проектов / Сергей Платонов (RAIDIX)Ontico
HighLoad++ 2017
Зал «Пекин+Шанхай», 7 ноября, 18:00
Тезисы:
http://www.highload.ru/2017/abstracts/2990.html
Мы ежедневно сталкиваемся с тем, что даже работающие более 15 лет в индустрии специалисты, путаются в понятиях и преимуществах и недостатках тех или иных архитектур больших СХД.
В своем докладе мы расскажем о разнице между distributed (распределенными), shared (общими) и параллельными файловыми системами, покажем, в каких задачах Scale In-системы превосходят Scale Out и наоборот.
...
Тест-драйв «Флеш СХД: битва титанов на сверхбыстрых скоростях» http://www.croc.ru/action/test-drives/42143/
Презентация Дмитрия Лямина, директора Центра решений КРОК на базе технологий Hitachi Data Systems
HDD, SSD, RAM, RAID, и кого на ком кэшировать / Михаил Конюхов (Perfect Solut...Ontico
Рассуждение, опыт, практика и примеры на тему производительности ввода-вывода.
Мы будем сравнивать "дефолтное" поведение SSD и HDD, сравним "недефолтное" поведение после тюнинга HDD. Я расскажу о плюсах и минусах в надежности HDD и SSD, о проблемах восстановления SSD и HDD после сбоев. Многие моменты будут посвящены кэшированию ввода-вывода, что очень помогает в реальных проектах.
Отдельная тема - оптимизация ФС и сервера для снижения количества операций ввода-вывода (IOPS), попробую оценить, что можно сделать с каким-нибудь проектом-примером.
Будут показаны и рассказаны реальные примеры из моего опыта оптимизации IO, я даже нарисую "карту принятия решения" для выбора накопителей для Вашего проекта.
Разработка OpenFlow-коммутатора на базе сетевого процессора EZchipARCCN
Доклад Васина Вячеслава (ЦПИКС) на семинаре Консорциума университетов по изучению и развитию передовых технологий в сфере компьютерных сетей. 20 октября 2016 года
Файловое хранилище Hitachi NAS 3200. Спецификация.Hitachi Nas
Файловое хранилище Hitachi NAS 3200. Спецификация.
Сетевая система хранения данных (NAS) от Hitachi предлагает масштабируемые решения для консолидации высокопроизводительных приложений корпоративного уровня, а также расширенные функциональные возможности для решений по консолидации файловых серверов организаций среднего размера.
Ключевые особенности:
Интеллектуальное перемещение файлов по уровням хранения позволяет реализовать иерархическое управление системами хранения данных (HSM) для платформ NAS и Content Platform от Hitachi
Сетевая система хранения данных с аппаратным ускорением, обеспечивающая пропускную способность до 700 Мбайт/с для последовательных операций и до 40 000 операций ввода/вывода в секунду
Возможность увеличения емкости хранилища до 4 петабайт
Интеграция с пакетом Hitachi Data Discovery Suite для эффективной индексации и поиска контента
Поэтапная модернизация, более быстрые переключения в случае аварий; сокращение времени плановых и внеплановых простоев
Кластеризация с включением по схеме «Active-Active» до двух узлов, обеспечивающая близкий к линейному рост производительности
Кэширование операций чтения для масштабируемой обработки запросов к NFS в случае большой доли таких операций
Кластерное пространство имен в целях унифицированной структуры каталогов
До 16 миллионов объектов на каталог
До 1024 «мгновенных снимков» на каждую файловую систему
Динамическое расширение файловых систем
До 64 виртуальных серверов с уникальными идентификаторами для аутентификации в AD, LDAP или NIS
http://hnas.hds.ru
Similar to Tarantool Silverbox, Юрий Востриков (20)
Facebook has over 500 million active users, with half logging in every day. It processes over 4 trillion feed actions per day and caches over 2 trillion objects. Facebook has scaled to over 1 million active users per engineer, significantly more efficient than other large tech companies. To achieve this scale, Facebook relies on techniques like frequent small releases, dark launching of major changes, and shedding load during outages to maintain reliability as the site grows enormously.
Shared Personalization Service - How To Scale to 15K RPS, Patrice PellandFuenteovejuna
The document summarizes the Shared Personalization Service (SPS) developed by Microsoft to enable explicit and implicit personalization at scale. SPS uses AppFabric caching and SQL partitioning to support 150 million home page visits per month with peaks of 15,000 requests per second. It provides a stateless architecture with no single point of failure and aims for read latencies less than 25ms and update latencies less than 50ms. SPS deploys across multiple regions using caching, databases, and file servers for availability and scalability.
Social Monitoring Tool codename Looking Glass, Patrice PellandFuenteovejuna
The document discusses the progression of a social monitoring incubation project from a Windows Server backend to Windows Azure.
It began as a Silverlight application with code reuse across Windows Phone and iOS. The initial backend used Windows Server and SQL Server but struggled to scale.
It then moved to using Windows Azure web and worker roles with SQL Azure and Azure storage to improve scalability. This allowed for distributed data acquisition and indexing to handle larger datasets.
The final phase utilized multiple Azure services including data aggregators, indexers, blob storage and visualization to create a more scalable, reliable and complex social monitoring solution. Moving to Azure addressed the project's scalability issues in a cost effective way.
Real time indexes in Sphinx, Yaroslav VorozhkoFuenteovejuna
This presentation introduces Sphinx Search 1.10's new real-time indexes feature. It discusses the problems with plain indexes and how real-time indexes allow indexing and updating data on the fly directly from MySQL. Performance tests show real-time indexes using less disk space and performing better for single and multi-queries compared to plain indexes, especially under load. The presentation demonstrates easy creation and CRUD of real-time indexes and migration tools and strategies.
3. Скорость разных типов памяти
Tape is dead, disk is tape, RAM is disk.
Задержка произвольного доступа
RAM — 25 ns
HDD — 8’000’000 ns
Пропускная способность последовательного доступа
RAM — 6’400 MB/s
HDD — 170 MB/s
5. Устройство SLAB аллокатора
Высокая скорость
Рассчитан на хранение множества мелких объектов
Низкие накладные расходы
Отсутствие внешней фрагментации
meta
alloc
free
. . .
free list
“phantom” pointers
4MB
6. Массаракш: код наизнанку
FSM, libev only
read1
read2
process
write1
loop
Fiber, libev+libcoro
read1
read2
process
write1
loop