форумы  помощь  поиск  регистрация  майллист  ВХОД  слежка

Вариант для распечатки		Архивированная нить - только для чтения!  Пред. тема | След. тема
Форумы OpenNET: Виртуальная конференция (Public)
Изначальное сообщение		[Проследить за развитием треда]

"In-Memory Storage: стратегии построения"
Сообщение от proff (ok) on 27-Май-04, 18:27  (MSK)
Коллеги, Прошу откликнуться тех, кто имел отношение к построению хранилищ данных с низким временем доступа, а также тех, кто интересуется этой тематикой. Тема весьма распространенная, так что возможно многие из вас с ней сталкивались. Возможно кто-нибудь посоветует уже реализованный механизм или как минимум компоненты, которые можно положить в основу. Это было бы просто удачей. Начну с задач, стоящих перед In-Memory Storage. 1. Быстрая скорость орбаботки запросов пользователей. Сами запросы от пользователей и наполнение данными самого хранилища происходит путем вызовов процедур, параметры которых -- примитивные типы данных (строка, int, double). 2. Устойчивость к отключениям питания и сбоям. Система хранит денюжки, а именно текущий (единственный и по этому актуальный) остаток на счетах абонентов. Следовательно денюжки терять нельзя. Нужно писать данные на энергонезависимую память. 3. Возможность "одновременной" обработки запросов многих бастродействующих клиентов (других серверных процессов). 4. Как можно более простая структура, программулина должна работать и на писюке с небольшой нагрузкой. В том числе и под Windows. Теперь собственно несколько мыслей относительно архитектуры самого программного девайса. 1. Оправданно ли использование RPC? Для масштабирования необходимо запускать несколько RPC-серверов, которые будут кидать в очередь, из кторой будет выгребать процесс-обработчик? Или RPC может масштабироваться как-то по другому? 2. Стратегии записи в файл. 2.1. Запросы на диске в виде файлов? Типа очередь запросов с момента запуска и до момента, определенного в конфиге (или путем вызова соотв. метода). Например, раз в сутки, или путем вызова соотв. метода, который блокирует storage, все из этих файлов синхронизируется со структурами в памяти, которые в виде "снимка" скидываются на диск. Сами файлики запросов удаляются. При старте -- обрабатываем запросы из очереди сначала и до конца. Может занять много времени. 2.2. Change log с точками сохранения?  Типа пишем приходящие запросы в файл change-log и храним их там до тех пор, пока не закончится таймаут или транзакция. Затем саму транзакцию или дельту за таймаут отражаем в другом файле -- типа снимке "статических" данных. Затем при сбое питания зачитываем снимок и по change-log'у восстанавливаем текущее положение вещей. Сам файл-снимок сделан в виде mmap(2). 2.3. Один "снимок", который сохраняется после каждой операции изменения  или по таймауту (mmap+msync)? Типа приходит запрос, мы его обрабатываем, вносим изменения в нашу структуру в памяти, которая отражается на файл и сохраняем изменения путем вызова msync(2). 2.4. Кикие-то другие варианты?
	Рекомендовать в FAQ | Cообщить модератору | Наверх

Индекс форумов | Темы | Пред. тема | След. тема

Сообщения по теме

1. "In-Memory Storage: стратегии построения"
Сообщение от proff (ok) on 28-Май-04, 15:33  (MSK)
Ситуация с хранилищем данных с маленьким временем доступа весьма стандартна: 1. Это может быть сервер свобеобразных очередей, хранящих запросы на обслуживание 2. Accounting сервер, как в моем случае 3. In-Memory DB, хранящая данные в строго фиксированном формате. 4. Что-то другое Например есть такой продукт Memcached, но он IMHO не подходит, т.к. он во-первых, не сохраняет данные в энергонезависимой памяти, а во-вторых, не выполняет никаких операций, кроме записи/выдачи/хранения данных...
	Рекомендовать в FAQ | Cообщить модератору | Наверх

	2. "In-Memory Storage: стратегии построения"
	Сообщение от proff (ok) on 28-Май-04, 15:42  (MSK)
	Немного сгруппировал способы организации архитектуры энергонезависимого хранилища. Получилось несколько независимых стратегий отличающихся друг от друга надежностью, воможностями масштабирования, скоростью восстановления, потребляемыми ресурсами. Основное их различие: вероятность потери данных, а также порядок сохранения данных в файлы на диске и, соответственно, то, как будет происходить восстановление после останова. 1. Запросы на диске в виде файлов. Типа очередь запросов с момента запуска и до момента, определенного в конфиге (или путем вызова соотв. метода). Например, раз в час или в момент наименьшей загрузки, или путем вызова соотв. метода, который блокирует storage, все из файлов запросов синхронизируется со структурами в памяти, которые в виде "снимка" скидываются на диск. Сами файлики запросов удаляются. При старте -- обрабатываем запросы из очереди сначала и до конца, что может занять много времени. Запись в файл каждого запроса -- медленная операция, зато каждый запрос не потерян. 2. Change log с точками сохранения. Типа пишем приходящие запросы в файл change-log и храним их там до тех пор, пока не закончится транзакция. Затем саму транзакцию отражаем в другом файле -- типа снимке "статических" данных. Зависшие транзакции откатываем (просто не делаем перенос в "симок") по таймауту. Затем при сбое питания зачитываем снимок и по change-log'у восстанавливаем текущее положение вещей. Сам файл-снимок сделан в виде mmap(2), т.е. под виндой memory mapped file. Также дисковая операция -- дописывание в конец файла, но экономия по отношению к предыдущему варианту на 2-х системных вызовах (open, close). Кроме этого, усложняем логику, вводя понятие транзакции. Более быстрое восстановление относительно предыдущего случая (насколько быстрее -- зависит от длины очереди сохраненных запросов). 3. То же что и в предыдущем случае, только файла change-log нет, на диск сбрасывается только транзакция целиком. Ускорение за счет уменьшения дискового обмена. Возможная потеря данных незавершенных транзакций. Быстрое восстановление -- зачитать с диска один файл. 4. Один "снимок", который сохраняется после каждой операции изменения или по таймауту (mmap+msync). Типа приходит запрос, мы его обрабатываем, вносим изменения в нашу структуру в памяти, которая отражается на файл и сохраняем изменения путем вызова msync(2). Замедление относительно предыдущего сильно вероятно, т.к. запись изменений на диск может осуществляться после каждого изменения структуры в памяти. Преимущество перед предыдущим в том, что отсутствует усложнение логики путем введения транзакций. Возможна потеря данных в случае сохранения на диск по таймауту. Быстрое восстановление -- зачитать с диска один файл.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

Удалить

Индекс форумов | Темы | Пред. тема | След. тема

Пожалуйста, прежде чем написать сообщение, ознакомьтесь с данными рекомендациями.