Каморка

Привет!

Нашёл я новую работу, а с ней и проблемы, с которыми раньше дела не имел. Подскажите, кто сталкивался, плз.

Система получает данные через сокет и задача её - эти данные неким образом сохранить. Сейчас всё хранится в отдельных файлах, на каждую "единицу клиента" - отдельный файл. Размеры файлов - ширина записи и их количество - примерно одинаковы, точнее, записи бывают всего 3 типов, соответственно есть 4 "типоразмера" файлов.
Данные приходят "пакетами", размер пакетов можно регулировать, но за 3 минуты должно пройти до 200к пакетов по 30 байт примерно. Для сети такой объем прокачать не проблема. В итоге за 3 минуты в каждый клиентский файл придёт один пакет (так сейчас).

Возник о scalability. Начали тестировать и выяснили, что на Win2000 Prof со SCSI диском больше, чем 500 файлов записать не получается. Точнее, когда файлов ВСЕГО 1000 - без проблем, но если число файлов растёт (и их хэндлы или ещё что-то, тут я не в курсе, не помещаются в кэш) - всё, кранты, на выборке из 10к файлов на запись в 500 из них уходит 5-7 секунд. А надо - в перспективе до 1млн файлов держать.
Итого: похоже, что отдельными файлами тут не обойтись. Первая идея - объединить нек. количество файлов в один. В принципе, работает, понятно, что создав достаточно большие файлы, на 1000 "клиентов" каждый, можно сделать их, файлов, количество управляемым. Первые тесты показали, что схема вроде как работоспособна. Но: хотелось бы знать о подводных камнях. Может ли вин2003 сервер многократно увеличить производительность такой схемы? Никогда не работал с Линукс, может быть, там всё быстрее? Есть ли там такой "фокус", как открытие одного файла на запись многократно разными потоками с возможностью блокировки отдельного участка непосредственно для обновления? (почти уверен, что есть, но всё же)

Кроме того, я, собственно, много работал с БД, с МС СКЛ в основном, но никогда с такими большими: размер базы "для начала" > 200ГБ, кол-во записей в таблице - около 8 млрд для начала. Соответственно, не представляю себе, какой сервер может потянуть такие размеры и апдейт 1000 записей в секунду (+ выборки), а пока уверенности нет, перетаскивать всё в базу нельзя.

All comments are highly appreciated.

Иосиф

сомеваюсь что в стеке у 2003 мастдая чтото поменялось.... вы можете попробовать воткнуть балансер вперед аппликейшен сервака тогда фалики будете между машинами сплитить.... если вы просто начнете файлики аггрегировать то наступит порог на котором вы скорее всего "приедете".

200Гб данных это нормально для скл сервера. максимальный размер я видет 2Тб на СКЛ Сервере 7. Тут все зависит от дизайна, будет бизайн скейлабл, потяните столько данных. другой вопрос возможно ли построить такой дизайн и как, тут я вам ничего не отвечу без конкретных данных что у вас, как используется итд.

[quote="папа Карло"]
... вы можете попробовать воткнуть балансер вперед аппликейшен сервака тогда фалики будете между машинами сплитить....
[/quote]
Тут понятно, возможность такую рассматриваем, хотя пока хотелось бы "обойтись" - серверы денежек стоят и их поддержка тоже. Но на будущее - может быть.
[quote="папа Карло"]
если вы просто начнете файлики аггрегировать то наступит порог на котором вы скорее всего "приедете".
[/quote]
В принципе, мы очень хорошо себе представляем предел, выше которого идти не придется, с точностью до порядка Мы знаем, что больше 1 млн. клиентов на этой схеме (в этом проекте) нам не грозит, количество данных на клиента тоже имеет чёткий предел, в разы расти не будет. Или речь не о таком "пороге", чего-то мы не замечаем?

[quote="папа Карло"]
200Гб данных это нормально для скл сервера. максимальный размер я видет 2Тб на СКЛ Сервере 7. Тут все зависит от дизайна, будет бизайн скейлабл, потяните столько данных. другой вопрос возможно ли построить такой дизайн и как, тут я вам ничего не отвечу без конкретных данных что у вас, как используется итд.
[/quote]
понятно, что можно всякие горизонал партишенинг использовать и что согласно кейс стади с мелкософта такие объемы саппортед легко. Вопрос - какой ценой?

Данные примерно такие:
1. номер клиента
2. некий идентификатор "времени" снятия данных, время со стандартным шагом, допустим, в 3 минуты. Т.е. 10:00, 10:03... Такой вот таймстамп, стандартный для всех клиентов.
3 - 15. данные, числа.

Поиск идёт только по клиенту + таймстампу, естественно, обычно необходимо брать некий период. Сейчас данные организованы в виде закольцованного буфера, т.е. количество записей на одного клиента фиксируется и при выходе за пределы периода всё просто переписывается с начала. Схема эта меняться не будет, просто некая саммари будет добавляться, по типу ОЛАП. Была у меня мысль иметь отдельную таблицу с указателем текущего таймстампа для клиента, чтобы индекс по таймстемпу не пересчитывать каждый раз. Тогда можно было бы вместо тайма в базовой таблице просто номер записи держать. Перед записью и чтением, понятно, пришлось бы этот указатель читать, но табличка достаточтно невелика, поместится в памяти, значит, выборка должна быть шустрой. Количество чтений их таблицы данных небольшое, но ОБЪЕМ данных при чтении может достигать 100к записей. В принципе, этого можно избежать, если математику, которая статистику считает по этим данным, загнать в ХП с курсорами, но хорошо ли это - большой вопрос, не хотелось напрягать сервер ничем, кроме хранения и выборки данных, с учетом того, что потеря данных недопустима (небольшая буферизация на сервере, который эти данные шлет, присутствует, поэтому короткий даун сервера базы не смертелен).

Иосиф

писать долго. по телефону было бы проще ок.... все выглядит так, что у вас есть "дивайсы" которые сбрасывают данные о клиентах.... похоже на телефонную станцию или типа того? заведите короткую базу... движек выбирать с максимальной скоростью инсертов. информачия не апдейтится я правильно понимаю? прирост рекордов за день какой будет? далее "ночью" откачиваете данные в хранилище в аггрегированном виде. при этом то что откачиватете надо кудата "забакапить" чтобы было потом откуда считывать в случае вопросов. партишенинг делается. это все вопрос дизайна и тоько дизайна. есои сидишь в канаде то можешь позвонить обсудим по телефону что там у вас и что нужно делать. если у вас так много данных и не знаете что с ними делать зовите меня. я знаю.

[quote="папа Карло"]
писать долго. по телефону было бы проще
[/quote]
запросто. Телефон?

[quote="папа Карло"]
ок.... все выглядит так, что у вас есть "дивайсы" которые сбрасывают данные о клиентах.... похоже на телефонную станцию или типа того? заведите короткую базу... движек выбирать с максимальной скоростью инсертов. информачия не апдейтится я правильно понимаю?
[/quote]
Всё правильно, только всё наоборот Всё ТОЛЬКО апдейтится, мы создаем "блок записей" под клиента и после этого - никаких вставок, только обновления, по кругу. А сбрасывают не дивайсы, а уже наш сервер, который эту инфу вначале собрал в буфер и теперь хочет сохранить в базу, находящуюся физически в другом месте.

[quote="папа Карло"]
при этом то что откачиватете надо кудата "забакапить" чтобы было потом откуда считывать в случае вопросов.
[/quote]
Вместо этого мы хотим посылать данные двум источникам с сервера - это прощё, потому как там уже буфер есть, организовать очень просто. Или имеется в виду - чтение отвести на "бэкап" сервер?

[quote="папа Карло"]
партишенинг делается. это все вопрос дизайна и тоько дизайна. есои сидишь в канаде то можешь позвонить обсудим по телефону что там у вас и что нужно делать. если у вас так много данных и не знаете что с ними делать зовите меня. я знаю.
[/quote]
Хорошо сказано, но сидим мы в Англии Хотя позвонить - по-прежнему запросто, хоть щас
На самом деле, первые тесты на файлах показали, что всё работает, но я весь это малтитрединг второй раз в жизни использую и что будет с этими локами только по хелпу представляю. А СКЛ сам вначале хотел, пока не узнал, каковы объемы данных. Как представлю себе, сколько времени займёт восстановление с бэкапа, если сервак упадёт, сразу хочется простых и понятных дисковых файлов.

Иосиф

ПМайл смотри...

У БД много других вкусностей. Транзакции например. Что если один из процессов недопишет свою запись до конца и умрет. Данные будут испорчены.


Если хочешь все таки файлы, то обрати внимание на маппирование памяти на файл. При работе с памятью вроде можно залочить кусок памяти(GetCriticalSection or something like that), в твоем случае запись. Т.е. в программе работаешь как с большим куском памяти, а физически это будет отображено на файл.
В Вин32 такое точно есть. В Линухе тоже должно.
Не знаю насчет ограничений на размер. Возможно только 4Гб.

[quote="MarkM"]У БД много других вкусностей. Транзакции например. Что если один из процессов недопишет свою запись до конца и умрет. Данные будут испорчены.[/quote]
Это понятно, я в курсе, транзакции хотелось бы, конечно. Просто цена у них есть, вот и считаем, можем заплатить столько или нет. Пока ответа 100% нет, потому что теоретическое решение не устраивает, спрашиваю практиков Были бы объемы записи поменьше - даже и думать бы не стал, а так без "гарантий" - страшно.

[quote="MarkM"]Если хочешь все таки файлы, то обрати внимание на маппирование памяти на файл. При работе с памятью вроде можно залочить кусок памяти(GetCriticalSection or something like that), в твоем случае запись. Т.е. в программе работаешь как с большим куском памяти, а физически это будет отображено на файл.
В Вин32 такое точно есть. В Линухе тоже должно.
Не знаю насчет ограничений на размер. Возможно только 4Гб.[/quote]
Понял. Я для начала сделал без мапирования, поскольку с ним никогда не работал, но вот локи на кусочки работают, очень удобно, конечно, несколько потоков могут в один файл спокойно писать или читать, только маленькие части блокируется. Почитатаю об этом обязательно, потому что важно обеспечить 100% сохранность данных на случай, если уже была дана "отмашка", что данные приняты успешно.

Иосиф

а если сделать еше одну апп которая будет подхватывать файлы и аплоадить в базу, что бы типа не занимань главную этим делом, пусть она продолжает создавать вайлы, а оно типа взяло-зауплоадило-удалило

Vovka писал(а):а если сделать еше одну апп которая будет подхватывать файлы и аплоадить в базу, что бы типа не занимань главную этим делом, пусть она продолжает создавать вайлы, а оно типа взяло-зауплоадило-удалило

Спасибо. Ты не поверишь - примерно такой вариант и стоит следующим в списке. Т.е. для начала смотрим, успеем ли распихивать данные в "большие" файлы, объединяющие группы "клиентов" (честно говоря, я бы и один большой файл сделал, но с точки зрения "потерять всё" уж слишком опасно, один файл скорее грохнется, чем 1000, да и восстановить с бэкапа быстрее) Затем, если этого мало, хотим добавить "кэш", чтобы туда всё подряд валилось, без разбора, какому клиенту принадлежит. А потом уже отдельным "джобом" этот кэш разбирать, чуть реже, чтобы можно было набрать несколько записей для каждого клиентского файла и тем самым снизить количество "открытий/закрытий". Ну и удалять после разбора. Это даже был вариант номер один, но потом решили поменять местами, потому как для "групп" больше готового кода есть. Но в принципе, так и хотим: лить по файлам, а уже дальше сливать куда-то, делать расчёты дополнительные, саммари и проч.
В принципе, это не так уж далеко от твоей идеи, вроде бы. Или я тебя немного не понял, тогда извини и поясни, плз.
Просто в отсутствие приличного сервера под СКЛ БД очень сложно предсказать, сколько апдэйтов в секунду он потянет, сколько времени будет занимать бэкап при таких размерах базы ну и т.д. Т.е. ситуация слегка запутанная, потому что надо делать тесты, но чтобы результаты были "правдивыми" нужно и сервер правильно настроить, и над оптимизацией базы поработать, и над дисковыми массивами. В итоге получается, что ради месяца тестирования (а времени мало) надо покупать сервер, приглашать разных спецов, а потом это всё может оказаться ненужным. Вот и пытаемся вначале опереться на опыт людей и провести более дешёвые тесты - без БД. Не прокатит - ну, судьба значит. Мне с такой базой поработать только в кайф было бы, но в данном случае проект важнее "личного интереса".

Иосиф

Почитал еще раз. ИМХО задача только для БД.
1млн клиентов, стробность 3 сек. ~350 изменений в сек.
Довольно круто для БД, но возможно.
Я б сделал так.
1. положил все в БД.
2. переделал бы апдэйты на инсерты. Инсерт дешевле для БД, т.к. в реду лог пишутся только новые данные. При апдэйте, и старые и новые.
3. Партиционировал бы данные по времени. Старые данные удалял бы убиением всего старого партишена.

Использование БД дает много плюсов в плане надежности и мэйнтенанса. Особенно если это 7х24х365.
Ну и репорты всякие без проблем.

Возможно работа напрямую с файлами будет и быстрее, но можно пролететь со см выше. В итоге создание и поддержка пропраитори системы управления записями может обойтись гораздо дороже.

смотри, берем подправляем апликуху чтобы она файлы писала по каконить соглашению (имена, размер и т.д.) можна даже делать .done файл для "закрытого" файла, другая сканит директорию и делает грубый лоад инфы в базу и потом херит этот файл, но тут есть ограничение, насколько я знаю для грязного load файл должен находится в физ. досягаемости сервера БД, скорость будь здоров, у меня файлик давольно таки "широкий" и гдето 350т записей (95М) лоадится несколько секунд это на хилом серваке и на простеньком сайбейз анивере. хотя в данном случае я думаю что скорость не важна т.к. вторая апп просто идет вдогонку.


пс. напоминаю для читателей шо я щас ищу работенку, причем сильно

MarkM писал(а):Почитал еще раз. ИМХО задача только для БД.
1млн клиентов, стробность 3 сек. ~350 изменений в сек.
Довольно круто для БД, но возможно.
Я б сделал так.
1. положил все в БД.
2. переделал бы апдэйты на инсерты. Инсерт дешевле для БД, т.к. в реду лог пишутся только новые данные. При апдэйте, и старые и новые.
3. Партиционировал бы данные по времени. Старые данные удалял бы убиением всего старого партишена.

Я, может, где-то не так выразился, там чуть другие цифры получаются.
За 3 МИНУТЫ цикла приходят данные по 1 млн клиентов (по максимуму). Это больше, чем 350, это ДО 5,5 тыс инсертов или апдейтов. Проблема, кроме того, состоит в том, что если делать инсерты, то точно придётся считать индексы, тогда как если делать через апдейты, можно обойтись "указателем" на последнюю запись для каждого клиента в отдельной табличке и не трогать индексы в основной совсем. Но опять-таки, просчитать, что будет быстрее, я не квалифайд, думаю, что всё же индексы будут прилично тормозить. Кстати, ты не можешь оценить, сколько времени займет инкрементал бэкап на такой базе, чтобы раз в день лог чикать? И насколько этот бэкап затормозит работу по вставке? Я уже подумал, что можно данные на диск лить. а потом bulk insert, тогда логов не будет, правда, и восстановления тоже

MarkM писал(а): Использование БД дает много плюсов в плане надежности и мэйнтенанса. Особенно если это 7х24х365.
Ну и репорты всякие без проблем.

Ну тут конечно, я ж говорю, я когда пришёл, первым делом удивился. почему не в базе всё. А потом... стал репу чесать. Конечно, выборка данных удобнее на порядок. Но с другой стороны, и сейчас чтение довольно просто происходит: открыл файл и N байт начиная с определенного места прочитал. Формат известен, поэтому всё легко и быстро. И даже индекс не нужен, потому что по сути в нужном порядке данные уже лежат (типа, кластеред ).

MarkM писал(а): Возможно работа напрямую с файлами будет и быстрее, но можно пролететь со см выше. В итоге создание и поддержка пропраитори системы управления записями может обойтись гораздо дороже.

Вот это как раз одна из причин, по которой файлы "рулез" - для них всё уже давно написано и живёт несколько лет, причём хорошо живёт (тьфу*3). Только на меньших объёмах. Потому и ищём для начала путь, чтобы суть не менять (проверял? не трогай!), но скэйлэбилити добиться. Не получится - будем с базой пробовать, но это точно намного дороже будет и дольше в разработке по понятным причинам.
Т.е. не пойми меня правильно , я ни один из вариантов не отвергаю, просто как всегда - баланс ищем.

Vovka писал(а): ...для грязного load...
хотя в данном случае я думаю что скорость не важна т.к. вторая апп просто идет вдогонку.

т.е. ты как раз балк лоад имеешь в виду? Там странно, потому что у меня коллега бывший сделал аппликуху для лоадов разных, так максимум, чего он добился, используя ОДБС компоненты, АПИ функции и все возможные выкрутасы из Дельфы - 2 тыс записей в секунду, насколько я помню.
Да, и скорость важна, конечно, потому что за секунду 1000 записей, а за минуту уже 60к соберется Так что тормозить особо нельзя.

Иосиф

Vovka писал(а): ...для грязного load...
хотя в данном случае я думаю что скорость не важна т.к. вторая апп просто идет вдогонку.

т.е. ты как раз балк лоад имеешь в виду? Там странно, потому что у меня коллега бывший сделал аппликуху для лоадов разных, так максимум, чего он добился, используя ОДБС компоненты, АПИ функции и все возможные выкрутасы из Дельфы - 2 тыс записей в секунду, насколько я помню.
Да, и скорость важна, конечно, потому что за секунду 1000 записей, а за минуту уже 60к соберется Так что тормозить особо нельзя.

Иосиф[/quote]
неправильно, лоад этот нужно делать на сервере, т.е. с того же Д ранить процедуру на серваке с параметром имя файла (типа к примеру)
у меня такое впечатление что я знаю о каком продукте реч идет, случайно не связан с чат клиентом?

неправильно, лоад этот нужно делать на сервере, т.е. с того же Д ранить процедуру на серваке с параметром имя файла (типа к примеру)

Ничего не понимаю (с) Файл на сервере - т.е. на том же компе, что и сервер? Если так - понятно, это и делалось. Ранить процедуру - т.е. таки использовать MS SQL Server bulk load option? Оно и использовалось. MS DTS тоже пробовали, тоже до 10к в секунду никогда не дотягивался на небольшом сервере.

у меня такое впечатление что я знаю о каком продукте реч идет, случайно не связан с чат клиентом?

Нет, не связан абсолютно.

Иосиф