Как пользоваться File Mapping?

← →
nikolo © (2002-08-05 11:03) [0]

Проблема в следующем. Есть огровный набор данных в MS SQL 2000, а обрабатывать его нужно в онлайне, т.е. скорость обработки должна быть очень большой. Слышал, что в таких случаях нужно загружать все данные в память и работать соответственно уже с ней. Кажется нужно использовать File Mapping. Подскажите, как именно это делается, желательно с небольшим примером. Пожет в Инете есть ссылки, где можно почитать на эту тему?

← →
Кулюкин Олег © (2002-08-05 11:25) [1]

http://www.delphikingdom.com/treasury/sharedstream01.htm

← →
nikolo © (2002-08-05 12:41) [2]

Да, классный пример! Но не понятно как этим делом пользоваться с БД? Допустим, я с помощью Query1 выбираю данные из Table1, Query2 выбираю данные из Table2 и так далее. Затем записываю данные с помощью TSharedStream в память, а как потом получать конкретные данные? Мне, например, надо вбырать из сохраненной таблицы одну строку, как ее выбрать?
Олег, может ты уже использовал TSharedStream именно с БД, покажи пример.

← →
Кулюкин Олег © (2002-08-05 12:53) [3]

Хм...
Какая разница откуда берутся данные? Из базы или еще откуда???
Работайте с TSharedStream как с обычным потоком.
Чтобы найти строку, видимо, придется считать разделители строк и выбирать кусок стрима. Все ручами.

Может Вам и не нужен File Mapping?
Расскажите о задаче подробнее.

← →
nikolo © (2002-08-05 13:53) [4]

Задача такая: в двух словах - обычный online billing, т.е. есть справочник абонентов, справочник устройств, справочник тарифных планов и еще несколько дополнительных справочников. В момент поступления звонка мне нужно быстро определить по справочнику владельца устройства, его тарифный план и т.д. Делать постоянно selectы из БД неприемлемо долго, поэтому и решил использовать память. Вот теперь пытаюсь понять как вся эта кухня работает, т.к. до сего времени с такими задачами не сталкивался.
Читая help по TStream, вроде бы понятно, что надо пользоваться как-то методами Read, Write, Seek. Но как именно и ими ли вообще, пока не понятно. Может все-таки скинете пару строк примера?

← →
nikolo © (2002-08-05 15:06) [5]

Еще вопрос. Допустим, в память я загнал какой-то select. Нужная строка находится где-то посередине 100000 записей. Как мне ее найти? Что надо становиться на начало Stream.Position := 0 и дальше делать Seek, пока не найду?

← →
Кулюкин Олег © (2002-08-05 15:07) [6]

Может стоит оптимизировать запросы, построить индексы...
Странный подход какой-то. Эмулировать СУБД в потоках

← →
nikolo © (2002-08-05 15:29) [7]

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

> Что надо становиться на начало Stream.Position := 0 и дальше
> делать Seek, пока не найду?

← →
Кулюкин Олег © (2002-08-05 15:50) [8]

2 nikolo © (05.08.02 15:29)
> Что надо становиться на начало Stream.Position := 0 и дальше
> делать Seek, пока не найду?
Да, вроде того.

Только это неверный подход.
Нехорошщо тащить данные на клиента.
См. Кулюкин Олег © (05.08.02 15:07)

← →
DmitryK © (2002-08-05 16:46) [9]

А помоему, народ, вы здесь фигней страдете.

СУБД для того и придумывали, что бы с большим объемом данных работать. И 100.000 записей при обработке запросов это далеко не предел.

Правильно спроектируй свою базу, разработай запросы корректно, и выполняться они будут всего 100-200 милисекунд (наиболее частый вариант) вместе с форматированием страниц (HTML).

Можешь еще поговорить с админом своей СУБД, пускай под тебя сервер настроит (например памяти ей больше выделит). Это тоже может помочь.

И даже не думай поднимать всю таблицу в память, у тебя легко могут уйти МИНУТЫ только на подгрузку всей этой информации, а поиск в памяти реализовывать намного сложнее, поиска по СУБД.

Возможно, тот кто тебе советовал работать с данными в памяти, имел ввиду строить временные таблицы в памяти, в таком случае это опять же к твоему админу сервера СУБД.

← →
Jeer © (2002-08-05 17:15) [10]

Помочь может разделение данных-таблиц по административному признаку.

← →
Suntechnic © (2002-08-05 17:18) [11]

>nikolo © (05.08.02 11:03)
Слушай DmitryK © он тебе дело говорит и не страдай фигнёй как он же правильно заметил.
Все те вопросы которые у тебя возникли это вопросы создания собственной СУБД. Ну и зачем тебе изобретать велосипед если его уже давно изобрели?

← →
nikolo © (2002-08-06 11:17) [12]

Да, вы, ребята, все дело говорите, как будто мне вот делать нечего и я просто решил ради развлечения нажить себе геморой.
Если бы речь шла о хранилищах данных типа какого-то склада, учата и всякой такой хрени, то и проблем-то не было бы, но! речь идет о OLPT-системе. Так вот, подсчитайте сколько будет времени уходить на на обработку почти полмиллиона транзакций в день, это же какая очередь будет выстраиваться? Работая же с памятью время обработки можно сократить на порядок.
А вообще, я задал вопрос простой - как работать с памятью, а вы демагогию разводите :) Лучше подскажите все-таки...

← →
nikolo © (2002-08-06 12:03) [13]

Что скажете?

← →
Кулюкин Олег © (2002-08-06 13:03) [14]

Если Вы будете хранить данные с структурах, то пользуйтесь примером из статьи о TSharedStream.
Там есть перебор всех записей, вы можете привернуть туда поиск.

← →
nikolo © (2002-08-06 17:37) [15]

Да, я посмотрел этот пример. Только вот не понял, необходимо что постоянно пользоваться перебором всех записей в памяти, чтобы что-то найти? Нет ли другого способа поиска?
Как нужно использовать метод Seek?

← →
Кулюкин Олег © (2002-08-06 17:53) [16]

Посмотрите (внимательно посмотрите) пример.
По нему можно слелать поиск.

От перебора вы не избавитесь никак :(

← →
nikolo © (2002-08-06 17:59) [17]

Перебором я уже сделал примерно так: становишся в начало Stream.Position := 0; и пока не удовлетворено какое-то условие делаю Stream.Read. Тут проблем нет. Но у меня будет очень большой объем данных в памяти, а искать нужно постоянно. Есть ли способ поиска без перебора? Для чего нужен метод Seek?
Может можно использовать как-то указатели?

← →
Fiend © (2002-08-06 18:04) [18]

То nikolo ©

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

У меня вот есть система, которая работает с большими таблицами просто мгновенно.

В одной таблице порядка 13 миллионов записей. Запрос к ней выполняется мгновенно. А всё потому что база правильно организована.

И еще: MS SQL достаточно умная машина, чтобы самостоятельно без вас закэшировать данные к которым выполняется частое обращение. На моём сервере 512 Мб мозгов. Таблица с 13 млн. записей весит около 380 Мб. Так вот после первого запроса, сервер без моих на то напоминаний ложит ее в память. И работает всё как по маслу.

Ну а если же вы будете тягать данные к клиенту в память, то не забудьте, что эти данные вам надо будет часто обновлять. И что ж вам опять кучку Мб на коиента тащить?
Это по крайней мере НЕРАЗУМНО.

← →
Кулюкин Олег © (2002-08-07 08:43) [19]

2 nikolo
> Для чего нужен метод Seek?
Посмотрите хелп, разве там это не описано???

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

← →
Fiend © (2002-08-07 09:30) [20]

То Кулюкин Олег

Геморрой, IMHO, бывает совсем не на шее, а в другом месте!
Ж))))))))
А под всем остальным подписываюсь без сомнений

← →
Кулюкин Олег © (2002-08-07 10:26) [21]

2 Fiend © (07.08.02 09:30)
> Геморрой, IMHO, бывает совсем не на шее, а в другом месте!
Я просто решил не углубляться в анатомию :))

← →
TSV © (2002-08-07 10:29) [22]

> nikolo ©
Проблема понятна.
Для ее решения хорошо использовать кэширование справочной информации на стороне сервера.
В MSSQL 2000 есть следующие вещи.
Во-первых, если к справочным таблицам часто применяется объединение ( join), но изменяются они редко, можно создать материализованный вид на основе этих таблиц.
Во-вторых, для маленьких таблиц-справочников, к которым идет частое обращение, можно применить операцию по помещению таблицы в память ( DBCC PINTABLE). Дополнительную инфу смотрите в BOL.

Удачи.

← →
TSV © (2002-08-07 10:31) [23]

И еще. Поработайте над оптимизацией индексов и хранимых процедур...

← →
alehan © (2002-08-07 11:10) [24]

-> nikolo 06.08.02 17:59
Высшее образование на что? Вспоминай алгоритмические языки программирования, теорию оптимизации, численные методы... :)
Если набор данных упорядочен по определённому полю, то при поиске по этому полю используется метод деления пополам.
http://www.aanet.ru/~web_k46/textbooks/str_alg/index2.htm

← →
nikolo © (2002-08-07 18:10) [25]

alehan ©, спасибо тебе большое! Ты единственный ответил просто на поставленный вопрос, не вдаваясь в то зачем мне это нужно. А все остальные... :(
То, что ты советуешь, я уже 2-й день мучаю, глянь на мою проблему: http://delphi.mastak.ru/cgi-bin/forum.pl?look=1&id=1028728806&n=1

← →
TSV © (2002-08-07 19:34) [26]

М-да...
Люди иногда оказываются неблагодарными...

Ты что думаешь, что сможешь, закачав инфу на клиента, найти информацию быстрее, чам сервер?
Уверяю тебя, ты заблуждаешься... А вот над оптимизацией своих SQL-запросов и оптимизацией структуры БД стоит серьезно задуматься...

← →
Slava © (2002-08-08 08:41) [27]

> TSV © (07.08.02 19:34)
> М-да...
> Люди иногда оказываются неблагодарными...

Люди чаще всего оказываются неблагодарными...

Да ладно вам, пусть человек попробует...
Набьет шишек, перестанет изобретать "лисапед".

2 nikolo
Я тоже просто ответил на поставленный вопрос (дал ссылку на статью по File Mapping) :)
Только, как видим, ответы порождают новые вопросы.

у него все получится, я уверен в этом

Ну, ребята, извините, если кого обидел. Расскажу чего за это время добился. Итак, насчет того, что лучше не гемороится с памятью, могу сказать однозначно, что вы не совсем правы. Я все же загрузил данные в память и делаю поиск методом деления диапозона пополам, ищет просто влет. Еще раз повторюсь, у меня OLTP система, в которой в секунду выполняется несколько от сотен до несколько тысяч запросов и делать постоянно selectы...:( Ведь, согласитесь, память она вот здесь прямо, а до сервака, который конечно работает влет, еще надо через кучу "прокладок" добраться. Так что...

2 nikolo
Вы эмулируете СУБД :)

Проверяли скорость на реальных объемах?

Зачем все загонять в память? Мочему не использовать какой-либо из DataSet"ов? Поиск в ДатаСете работает медленнее?
ClientDataSet умеет индексировать и искать с учетом индекса.

← →
RedWood (2002-08-08 11:17) [32]

Всем привет !
У меня тут всплыло несколько вопросов :
1. Если есть такое огромное количество записей,
то хватит ли клиенту физической оперативной памяти,
не начнет ли он свопить ?
2. Как будут обновлятся данные ?
Полностью согласен, что нужно оптимизировать БД
Сам я работаю с Информиксом, есть таблицы в несколько
милионов записей, проблем с выборкой одной записи
по простому запросу (насколько я понял тут запросы простые)
не возникает. Настрой индексы под свои запросы, оптимизируй
запросы, если это возможно.
П.С.
Если я не ошибаюсь, то есть методы поиска бестрее чем
половинного деления. Но могу ошибаться ...

Я очень извиняюсь, но не думаю, что проектируемая билинговая система обрабатывает поток насыщеннее, чем МТС или БИЛАЙН, а они используют СУБД. В конторе, которая написала один из самых мощных билинговых пакетов CBOSS вообще кроме Oracle Developer и Oracele Desiner никакими продуктами не пользуются. В БИЛАЙН умудряются использовать не самый быстрый BTRIVE. Так что решать Вам, но все остальные тоже не дуракию
Удачи.

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

> nikolo © (08.08.02 11:00)

А зачем делать все на клиенте?
Тебе надо создать хранимую процедуру или несколько процедур.
А дальше с клиента ты просто делаешь вызов процедуры с параметрамию И все... Никаких прокладок. Все выполняется локально на сервере... Вот это и есть - серверная логика...

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

> Если я не ошибаюсь, то есть методы поиска бестрее чем
> половинного деления. Но могу ошибаться ...

и автора обсуждения этот вопрос тоже интересовал.

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

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

Но и это еще не все, возьми классический алгоритм B-дерева, и ты получишь ускорение уже даже не в разы, а на порядки.

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

2 RedWood (08.08.02 11:17)
> Если есть такое огромное количество записей, то хватит ли клиенту физической оперативной памяти, не начнет ли он свопить ?
Начнет, причем сразу.
File Mapping это и есть работа со свопом. :)

← →
Мышь (2002-08-09 04:42) [38]

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

> nikolo © (06.08.02 11:17)
Если бы речь шла о хранилищах данных типа какого-то склада, учата и всякой такой хрени, то и проблем-то не было бы, но! речь идет о OLPT-системе. Так вот, подсчитайте сколько будет времени уходить на на обработку почти полмиллиона транзакций в день, это же какая очередь будет выстраиваться? Работая же с памятью время обработки можно сократить на порядок.

Конечно. Сократить время. Далее, написать систему обработки транзакций самому. Ну-ну. Слушай DmitryK © (05.08.02 16:46)

Как пользоваться File Mapping? Найти похожие ветки