Вопрос архитекторам

[Иосиф]

3. Партиционировал бы данные по времени. Старые данные удалял бы убиением всего старого партишена.

Да, Марк, ещё один момент забыл. Все выборки идут не по времени, а по клиенту. Это как раз причина для того, чтобы под клиента сразу создавать "блок записей". Т.е. приходят данные по времени, а читаются - по клиенту. Будет ли шустро работать выборка десятков тыс. записей (для вычислений часто нужны все данные по клиенту), если за каждой нужно в индекс слазить? И апдейт того индекса тоже...

Иосиф

[MarkM]

5500 строк в сек. Для БД тяжеловато будет. Такая нагрузка равномерная? Или есть суточные вариации?
Да, наверное типизированные файлы это только и выход.

Но гонять по ним репорты. Сакс. Негибко. Хотя, если у вас уже все готово, то ОК.

Тогда я не понял в чем у вас проблема масштабирования? Добавьте памяти. %)

Любая СУБД будет медленне файлов. Т.к. она делает некоторые избыточные вещи. Ну ты сам знаешь.

Если хочется гибких репортов, то я бы грузил все в БД раз в сутки.

Кстати, а ты не пробовал Оракл? У него есть мощный лоадер, грузит файлы в БД со страшной силой. И у 9и есть мапирование таблиц на файлы. Т.е. твои файлы из Оракла будут видны как таблицы.

Про партиционирование я говорил в плане, что ротация записей у вас идет по времени. Старые записи затираются новыми. Партишены в БД аналогично. Партишн 30 дневной даности удаляется, партишен на завтра вставляется. Ротация.
Но я повторяю. У БД больше накладных расходов. Изза ее гибкости, надежности, мэйнтэйнабилити и тд.

Какие у вас приоритеты?
- цена и скорость - файлы
- надежность и гибкость - БД

[Иосиф]

5500 строк в сек. Для БД тяжеловато будет. Такая нагрузка равномерная? Или есть суточные вариации?
Да, наверное типизированные файлы это только и выход.

Нагрузка абсолютно равномерная.

Тогда я не понял в чем у вас проблема масштабирования? Добавьте памяти. %)

Только в том, что в настоящий момент используется структура 1 клиет - 1 файл. Соотв. при росте числа клиентов ОС (и харддрайв со своим кэшем), похоже, перестаёт справляться с таким числом файлов, на "открыть" слишком много времени уходит. Процессор свободен, всего 15% загрузки, память тоже, вроде, не вся используется. Думаем, что всё-таки хард. Поэтому и пытаемся объединять "нынешние" файлы в группы, составляющие один новый файл по принципу 1000:1 или что-то в этом роде. Собственно, я даже думал, что кто-нибудь из тех, кто ближе к железу сможет подкинуть идею насчёт использования супер-пупер дисковых массивов, контроллеров и т.п. Но на вечер пятницы была надежда, что объединение работает и даёт достаточную производительность. Завтра проверим ещё раз.

Кстати, а ты не пробовал Оракл? У него есть мощный лоадер, грузит файлы в БД со страшной силой. И у 9и есть мапирование таблиц на файлы. Т.е. твои файлы из Оракла будут видны как таблицы.

т.е я могу в Оракле создать 10**6 таблиц и натравить их на файлы? Или даже одну, независимо от числа файлов? Было бы круто, потому что выборка и консолидация упростились бы. А сколько времени в Оракле бэкап займёт? И как будет бэкапиться такая база, с мапированием дисковых файлов - средствами ОС или Оракла? И сколько времени занимает восстановление с бэкапа, допустим, 100 Гб базы? Думаю, что по крайней мере вся база для бэкапа не блокируется, т.е. данные можно будет продолжать апдейтить...

Какие у вас приоритеты?
- цена и скорость - файлы
- надежность и гибкость - БД

Вы будете смеяться (с) - скорость и надёжность Потом цена, а гибкость почти не важна, потому что продукт наш, подгоняться под клиентов не будет - только под технологии, которые более или менее известны (в данной области). Ну а все внутренние данные системы, конечно, в базе лежат, правда, пока в DBISam, но это вопрос времени.

Иосиф

[MarkM]

.е я могу в Оракле создать 10**6 таблиц и натравить их на файлы?

[trn]V BD tak obychno ne delajut[/trn]

Или даже одну,

[trn]V BD tak obychno delajut[/trn]

независимо от числа файлов? Было бы круто, потому что выборка и консолидация упростились бы.

[trn]Faily i tablicy mapjatsja 1:1[/trn]

А сколько времени в Оракле бэкап займёт? И как будет бэкапиться такая база, с мапированием дисковых файлов - средствами ОС или Оракла?

[trn]OS. Vremja zavisit ot skorosti zheleza. Obychno ogranicheno skoros'ju lenty ~500Mb/min. Ot Orakla ne zavisit.
V Orakl Enterpajz Edishn mozhno bekapit' inkrementno, tol'ko izmenennye bloki BD.
[/trn]

И сколько времени занимает восстановление с бэкапа, допустим, 100 Гб базы?
[trn]Stolko zhe skol'ko i bakap. Zavisit ot skorosti lenty.[/trn]


Думаю, что по крайней мере вся база для бэкапа не блокируется, т.е. данные можно будет продолжать апдейтить...

[trn]Da dannye mozhno izmenjat' vo vremja bakapa.[/trn]

[Иосиф]

[trn]Faily i tablicy mapjatsja 1:1[/trn]

Это грустно... но поправимо.

В остальном всё понятно, большое спасибо за ответы и советы. Будем над этим работать

Иосиф

[MarkM]

потестировал на оракле 8.0.
тачила древняя, лет 5. Двойной пень 400мгц. СКАЗИ райд 5 на трех винтах. 1 гиг ОЗУ, занято 300мб.

таблица
create table tst(id number, n1 number, n2 number, n3 number, n4 number, n5 number, s varchar(30));

100000 инсетров , коммит на каждый инсерт - 1400 строк/сек

100000 апдейтов, ID выбран псевдо-рандомли, коммит на каждый инсерт - 1400 строк/сек

100000 апдейтов, ID выбран псевдо-рандомли, коммит на каждые 1000 строк, - 2380 строк/сек

100000 инсертов, коммит на каждые 1000 строк, - 2500 строк/сек

загрузка проца 50-60-70%. Один поток. Все изменения логятся.

Есть резервы для улучшения. Балк инсерт или апдэйт (сразу много строк пачкой). Многопоточность. Лучше и балк и Многопоточность.
Например, апп открывает несколько оракл-сессий и делает балк инсерт каждые 3 сек по всем клиентам, какие пришли на вход.

Директ лоад или внешние таблицы тоже должны сильно ускорить. За счет надежности, правда.

Экстенсивные резервы улучшения - заюзать больше ОЗУ, апгрэйднуть железо. Положить базу на РАЙД10
Т.е. при серваке за 5К и Энтерпрайз Оракле можно построить быструю надежную масштабируемую(!) систему. Энтерпрайз нужен для партиционирования и инкрементального бэкапа. Энтерпрайз подороже будет однако, но при 200Гб базе оно стоит того.

[Иосиф]

Марк, большое спасибо. Показал боссу (он в школе учил русский, кое-что без перевода понял ), решили, что теперь у нас есть запасной вариант на случай, если будут проблемы с файлами (всё же быстрее с них начинать, сейчас просто нужно доказать, что мы в состоянии такие количества хэндлить). То, что вставка и апдейт не сильно отличаются по времени - тоже приятно, оставляет больше выбора. + подходящее время бэкапа.

Я только чуть торможу, ты дал пример 1000 строк - 1 коммит, это НЕ то же самое, что балк апдейт? На МС СКЛ балк - это лоад внешних данных, без логгинга, насколько я помню. У вас это похоже директ лоад называется Или ты имел в виду - просто больше записей, не 1000, а 50К? Я помню, что на нашем МС ( в старой конторе) была проблема, потому что слишком длинная транзакция долго в логах ковырялась, похоже. Но у нас всё было на одном диске - и данные, и лог, потому - не показатель, конечно.

Иосиф

[MarkM]

[trn]
v moem primere bylo vypusheno 100tys SQL stejtmentov(v cykle). Vo vtorom sluchae kommit delalsja cherez kazhdye 1000 stejtmentov.
v oracle balk znachit insertnut mnogo strok odnim stejtmentom, vhodnoj parameter(y) eto massiv so znachenijami dlja kazhdoj stroki.
Tipa insertnut' srazu 1000 strok odnim stejtmentom. Ekonomitsja vremja na mjagkom parsinge i proverke privilegij. Chto v sluchae s 1000 stejtmentami budet delat'sja 1000 raz.
Bol'shie tranzakcii tebe delat' tozhe ne rezon.
Ja by delal vstavku balkom vsego chto prishlo za 3 min. Mozhno rasshepit' po neskol'kim processam vruchnuju ili ispol'zovat' Parallel Query, kotoryj est' v enterpajze. Delaetsja deklarativno, na tablicu objavljaetsja koeff parallelizma i orakl sam sozdast nuzhnoe kol-vo slejvov dlja vstavki. V programme menjat' dazhe nicho ne nado.
[/trn]

[папа Карло]

[trn]
v moem primere bylo vypusheno 100tys SQL stejtmentov(v cykle). Vo vtorom sluchae kommit delalsja cherez kazhdye 1000 stejtmentov.[/trn]

по сети вставлял или локально на серваке запускал?

[Иосиф]

Всё, разобрался, о каком балке речь идёт, это ж не анси скл, вот я и ломал голову Да, похоже, там неплохо ускориться можно ещё.
А многопоточность используем, если понадобится, удобно, конечно, что алликухе до этого дела нет.
У нас, кроме того, данные идут блоками и их размер мы можем регулировать, так что это ещё одна возможность удобно всё организовать. Сейчас блок приходит ежесекундно и под него создаётся поток, чья задача распарсить всё и сохранить, так что потоки Ораклу гарантированы в любом случае

Иосиф

[Yocto]

Если речь идет о NTFS, то можно использовать один большой sparse файл для большого числа клиентов. Порезать его на секции предопределённого размера, скажем. в 1Gb.

[Иосиф]

Если речь идет о NTFS, то можно использовать один большой sparse файл для большого числа клиентов. Порезать его на секции предопределённого размера, скажем. в 1Gb.

Мой единственный аргумент против одного файла - сложно поддерживать (бэкап/рестор, опасность ухнуть вообще всё одним разом при сбое). Возможно, это чисто психологический эффект, страх от незнания.


Иосиф

[Yocto]

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

[Иосиф]

Подобные страхи легко лечатся непрограммными средствами.

Возможно. И образованием

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

Тут я не понял. Как это я могу без сервера базы обойтись? Или ты о выборе файл против РДБМС? Я когда сказал, что против ОДНОГО файла имел в виду, что буду использовать много, в пределах 1000. Т.е. для меня "сервер базы" в этой ситуации - аппликуха, которая данные по файлам раскладывает, без неё всё равно никуда.

Иосиф

[Yocto]

А зачем иметь тысячу файлов?
Создай один sparse файл, длиной в 1000Gb, где каждому клиенту отведено 1Gb виртуального дискового пространства. Понятно, что область, принадлежащая каждому клиенту будет высчитываться по смещению относительно начала файла. Ты избегаешь замусоривания MFT и сохраняешь все прелести непосредственного чтения с диска вместо обращения к серверу базы.