| Форумы
ЧАТ |
Орешник |
|
| Форумы -» | Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG |
|
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
Как пользоваться File Mapping? [D5, MSSQL]
nikolo © (2002-08-05 11:03:00)Проблема в следующем. Есть огровный набор данных в MS SQL 2000, а обрабатывать его нужно в онлайне, т.е. скорость обработки должна быть очень большой. Слышал, что в таких случаях нужно загружать все данные в память и работать соответственно уже с ней. Кажется нужно использовать File Mapping. Подскажите, как именно это делается, желательно с небольшим примером. Пожет в Инете есть ссылки, где можно почитать на эту тему?
Владислав (2002-08-09 08:51:00) [1]> nikolo © (06.08.02 11:17)
Если бы речь шла о хранилищах данных типа какого-то склада, учата и всякой такой хрени, то и проблем-то не было бы, но! речь идет о OLPT-системе. Так вот, подсчитайте сколько будет времени уходить на на обработку почти полмиллиона транзакций в день, это же какая очередь будет выстраиваться? Работая же с памятью время обработки можно сократить на порядок.
Конечно. Сократить время. Далее, написать систему обработки транзакций самому. Ну-ну. Слушай DmitryK © (05.08.02 16:46)
Мышь (2002-08-09 04:42:00) [2]Вообще, в таких вещах, как справочники абонентов и т.д., легко строятся уникальные индексы, по которым при своевременном их обновлении поиск в Базе будет производиться очень быстро. А перетаскивать Базу на локальную машину - это не очень хорошо и имеет смысл, если постоянно нужна вся информация из нее. Так что попробуй поиграться с индексами.
Кулюкин Олег (2002-08-08 14:38:00) [3]2 RedWood (08.08.02 11:17)
> Если есть такое огромное количество записей, то хватит ли клиенту физической оперативной памяти, не начнет ли он свопить ?
Начнет, причем сразу.
File Mapping это и есть работа со свопом. :)
DmitryK (2002-08-08 13:43:00) [4]Извиняюсь, что поднимаю тему от которой автор уже отказался, но здесь писали:
> Если я не ошибаюсь, то есть методы поиска бестрее чем
> половинного деления. Но могу ошибаться ...
и автора обсуждения этот вопрос тоже интересовал.
Конечно же есть и лучшие алгоритмы, например метод золотого сечения, примерно тоже что и метод половинного деления, но работает в некотрых случаях эффективнее.
Вот еще неплохой алгоритм - бинарные деревья, если такое дерево правильно построить (удачно распределить ключи), то ускорить поиск можно в разы.
Но и это еще не все, возьми классический алгоритм B-дерева, и ты получишь ускорение уже даже не в разы, а на порядки.
Но вся петрушка в том, что все эти алгоритмы (а если быть более точным, их модифицированные, и работающие еще быстрее, варианты) уже реализованы в СУБД. Плюс, тебе не надо таскать по несколько миллионов записей между клиентом и сервером, что многократно увеличивает скорость доступа к данным (как на просмотр, так и на изменение). И что еще более важно, СУБД обеспечивает куда более высокий уровень защиты информации (причем, как от несанкционированного доступа, так и от потери данных).
TSV (2002-08-08 12:57:00) [5]> nikolo © (08.08.02 11:00)
А зачем делать все на клиенте?
Тебе надо создать хранимую процедуру или несколько процедур.
А дальше с клиента ты просто делаешь вызов процедуры с параметрамию И все... Никаких прокладок. Все выполняется локально на сервере... Вот это и есть - серверная логика...
nikolo (2002-08-08 12:56:00) [6]Все, всем спасибо, тему будем считать закрытой. Если в будущем мы все-таки откажемся от использования памяти и будем как все нормальные люди использовать СУБД, я вам обязательно об этом сообщу.
Еще раз всех благодарю за токое активное обсуждение темы.
ShuraGrp (2002-08-08 11:59:00) [7]Я очень извиняюсь, но не думаю, что проектируемая билинговая система обрабатывает поток насыщеннее, чем МТС или БИЛАЙН, а они используют СУБД. В конторе, которая написала один из самых мощных билинговых пакетов CBOSS вообще кроме Oracle Developer и Oracele Desiner никакими продуктами не пользуются. В БИЛАЙН умудряются использовать не самый быстрый BTRIVE. Так что решать Вам, но все остальные тоже не дуракию
Удачи.
RedWood (2002-08-08 11:17:00) [8]Всем привет !
У меня тут всплыло несколько вопросов :
1. Если есть такое огромное количество записей,
то хватит ли клиенту физической оперативной памяти,
не начнет ли он свопить ?
2. Как будут обновлятся данные ?
Полностью согласен, что нужно оптимизировать БД
Сам я работаю с Информиксом, есть таблицы в несколько
милионов записей, проблем с выборкой одной записи
по простому запросу (насколько я понял тут запросы простые)
не возникает. Настрой индексы под свои запросы, оптимизируй
запросы, если это возможно.
П.С.
Если я не ошибаюсь, то есть методы поиска бестрее чем
половинного деления. Но могу ошибаться ...
Кулюкин Олег (2002-08-08 11:10:00) [9]2 nikolo
Вы эмулируете СУБД :)
Проверяли скорость на реальных объемах?
Зачем все загонять в память? Мочему не использовать какой-либо из DataSet"ов? Поиск в ДатаСете работает медленнее?
ClientDataSet умеет индексировать и искать с учетом индекса.
nikolo (2002-08-08 11:00:00) [10]Ну, ребята, извините, если кого обидел. Расскажу чего за это время добился. Итак, насчет того, что лучше не гемороится с памятью, могу сказать однозначно, что вы не совсем правы. Я все же загрузил данные в память и делаю поиск методом деления диапозона пополам, ищет просто влет. Еще раз повторюсь, у меня OLTP система, в которой в секунду выполняется несколько от сотен до несколько тысяч запросов и делать постоянно selectы...:( Ведь, согласитесь, память она вот здесь прямо, а до сервака, который конечно работает влет, еще надо через кучу "прокладок" добраться. Так что...
Polevi (2002-08-08 09:43:00) [11]у него все получится, я уверен в этом
Кулюкин Олег (2002-08-08 09:18:00) [12]Да ладно вам, пусть человек попробует...
Набьет шишек, перестанет изобретать "лисапед".
2 nikolo
Я тоже просто ответил на поставленный вопрос (дал ссылку на статью по File Mapping) :)
Только, как видим, ответы порождают новые вопросы.
Slava (2002-08-08 08:41:00) [13]> TSV © (07.08.02 19:34)
> М-да...
> Люди иногда оказываются неблагодарными...
Люди чаще всего оказываются неблагодарными...
TSV (2002-08-07 19:34:00) [14]М-да...
Люди иногда оказываются неблагодарными...
Ты что думаешь, что сможешь, закачав инфу на клиента, найти информацию быстрее, чам сервер?
Уверяю тебя, ты заблуждаешься... А вот над оптимизацией своих SQL-запросов и оптимизацией структуры БД стоит серьезно задуматься...
nikolo (2002-08-07 18:10:00) [15]alehan ©, спасибо тебе большое! Ты единственный ответил просто на поставленный вопрос, не вдаваясь в то зачем мне это нужно. А все остальные... :(
То, что ты советуешь, я уже 2-й день мучаю, глянь на мою проблему: http://delphi.mastak.ru/cgi-bin/forum.pl?look=1&id=1028728806&n=1
alehan (2002-08-07 11:10:00) [16]-> nikolo 06.08.02 17:59
Высшее образование на что? Вспоминай алгоритмические языки программирования, теорию оптимизации, численные методы... :)
Если набор данных упорядочен по определённому полю, то при поиске по этому полю используется метод деления пополам.
http://www.aanet.ru/~web_k46/textbooks/str_alg/index2.htm
TSV (2002-08-07 10:31:00) [17]И еще. Поработайте над оптимизацией индексов и хранимых процедур...
TSV (2002-08-07 10:29:00) [18]> nikolo ©
Проблема понятна.
Для ее решения хорошо использовать кэширование справочной информации на стороне сервера.
В MSSQL 2000 есть следующие вещи.
Во-первых, если к справочным таблицам часто применяется объединение ( join), но изменяются они редко, можно создать материализованный вид на основе этих таблиц.
Во-вторых, для маленьких таблиц-справочников, к которым идет частое обращение, можно применить операцию по помещению таблицы в память ( DBCC PINTABLE). Дополнительную инфу смотрите в BOL.
Удачи.
Кулюкин Олег (2002-08-07 10:26:00) [19]2 Fiend © (07.08.02 09:30)
> Геморрой, IMHO, бывает совсем не на шее, а в другом месте!
Я просто решил не углубляться в анатомию :))
Fiend (2002-08-07 09:30:00) [20]То Кулюкин Олег
Геморрой, IMHO, бывает совсем не на шее, а в другом месте!
Ж))))))))
А под всем остальным подписываюсь без сомнений
| |
Страницы: 