База данных с высокоскоростным не параллельным управлением
Формула / Реферат
1. Система многопоточной сетевой базы данных, содержащая
по меньшей мере один процессор, связанный с сетью, и
память, связанную с процессором, причем память содержит базу данных и команды, предназначенные для выполнения процессором, для
создания потока обновления и множества потоков поиска,
назначения каждого из множества запросов на поиск, полученных через сеть, одному из множества потоков поиска,
для каждого потока поиска:
осуществления поиска по базе данных в соответствии с назначенными запросами на поиск,
создания множества ответов по поиску, соответствующих назначенным запросам на поиск, и
передачи множества ответов по поиску через сеть, и
для потока обновления:
создания нового элемента в соответствии с новой информацией, полученной через сеть, и
без ограничения доступа к базе данных для множества потоков поиска, записи указателя на новый элемент в базу данных с использованием одиночной непрерываемой операции.
2. Система по п.1, отличающаяся тем, что одиночная непрерываемая операция представляет собой команду сохранения.
3. Система по п.1, отличающаяся тем, что дополнительно содержит для потока обновления:
физическое удаление существующего элемента из памяти после записи указателя в базу данных.
4. Система по п.2, отличающаяся тем, что команда сохранения записывает 4 байта в адрес памяти, размещенный на границе 4 байтов.
5. Система по п.2, отличающаяся тем, что команда сохранения записывает восемь байтов в адрес памяти, размещенный на границе 8 байтов.
6. Система по п.2, отличающаяся тем, что процессор имеет длину машинного слова по меньшей мере в n-байтов, память имеет разрядность по меньшей мер в n-байтов и команда сохранения записывает n-байтов в адрес памяти, размещенный на n-байтовой границе.
7. Система по п.1, отличающаяся тем, что множество запросов на поиск принимается в одиночном пакете сети.
8. Система по п.1, отличающаяся тем, что множество ответов по поиску передается в одиночном пакете сети.
9. Система по п.1, отличающаяся тем, что упомянутое ограничение доступа включает в себя блокировку базы данных.
10. Система по п.1, отличающаяся тем, что упомянутое ограничение доступа включает в себя взаимоблокировку.
11. Система по п.10, отличающаяся тем, что взаимоблокировка включает в себя использование по меньшей мере одного семафора.
12. Система по п.11, отличающаяся тем, что упомянутый семафор является семафором мьютекса.
13. Система по п.1, отличающаяся тем, что дополнительно содержит множество процессоров и симметричную многопроцессорную операционную систему.
14. Система по п.13, отличающаяся тем, что множество потоков поиска выполняет по меньшей мере 100000 поисков в секунду.
15. Система по п.14, отличающаяся тем, что поток обновления выполняет по меньшей мере 10000 обновлений в секунду.
16. Система по п.15, отличающаяся тем, что поток обновления выполняет от 50000 до 130000 обновлений в секунду.
17. Система по п.1, отличающаяся тем, что указатель на новый элемент записан в индекс поиска.
18. Система по п.17, отличающаяся тем, что индекс поиска представляет собой TST (тернарное дерево поиска).
19. Система по п.17, отличающаяся тем, что индекс поиска представляет собой хэш-таблицу.
20. Система по п.1, отличающаяся тем, что указатель на новый элемент записан в запись данных в базе данных.
21. Способ поиска и параллельного обновления базы данных, заключающийся в том, что
создают поток обновления и множество потоков поиска,
назначают каждый из множества запросов на поиск, полученных через сеть, одному из множества потоков поиска,
для каждого потока поиска:
осуществляют поиск по базе данных в соответствии с назначенными запросами на поиск,
создают множество ответов по поиску, соответствующих назначенным запросам на поиск, и
посылают множество ответов по поиску через сеть, и
для потока обновления:
создают новый элемент в соответствии с новой информацией, полученной через сеть, и
без ограничения доступа к базе данных для множества потоков поиска записывают указатель на новый элемент в базу данных с использованием одиночной непрерываемой операции.
22. Способ по п.21, отличающийся тем, что одиночная непрерываемая операция представляет собой команду сохранения.
23. Способ по п.21, отличающийся тем, что дополнительно для потока обновления физически удаляют существующий элемент после записи указателя в базу данных.
24. Способ по п.22, отличающийся тем, что команда сохранения записывает 4 байта в адрес памяти, размещенный на границе 4 байтов.
25. Способ по п.22, отличающийся тем, что команда сохранения записывает 8 байтов в адрес памяти, размещенный на границе 8 байтов.
26. Способ по п.21, отличающийся тем, что множество запросов на поиск принимают в одиночном пакете сети.
27. Способ по п.21, отличающийся тем, что множество ответов по поиску принимают в одиночном пакете сети.
28. Способ по п.21, отличающийся тем, что упомянутое ограничение доступа включает в себя блокировку базы данных.
29. Способ по п.21, отличающийся тем, что упомянутое ограничение доступа включает в себя взаимоблокировку.
30. Способ по п.29, отличающийся тем, что взаимоблокировка включает в себя использование по меньшей мере одного семафора.
31. Способ по п.30, отличающийся тем, что упомянутый семафор является семафором мьютекса.
32. Способ по п.21, отличающийся тем, что множество потоков поиска выполняют по меньшей мере 100000 поисков в секунду.
33. Способ по п.32, отличающийся тем, что поток обновления выполняет по меньшей мере 10000 обновлений в секунду.
34. Способ по п.33, отличающийся тем, что поток обновления выполняет от 50000 до 130000 обновлений в секунду.
35. Способ по п.21, отличающийся тем, что указатель на новый элемент записан в индекс поиска.
36. Способ по п.35, отличающийся тем, что индекс поиска представляет собой TST.
37. Способ по п.21, отличающийся тем, что указатель на новый элемент записан в запись данных в базе данных.
38. Носитель информации, считываемый компьютером, содержащий команды, предназначенные для выполнения по меньшей мере одним процессором, для выполнения способа поиска и параллельного обновления базы данных, включающего в себя
создание потока обновления и множества потоков поиска,
назначение каждого из множества запросов на поиск, полученных через сеть, одному из множества потоков поиска,
для каждого потока поиска:
осуществление поиска по базе данных в соответствии с назначенными запросами на поиск,
создание множества ответов по поиску, соответствующих назначенным запросам на поиск, и
передачу множества ответов по поиску через сеть, и
для потока обновления:
создание нового элемента в соответствии с новой информацией, полученной через сеть, и
без ограничения доступа к базе данных для множества потоков поиска, запись указателя на новый элемент в базу данных с использованием одиночной непрерываемой операции.
39. Носитель информации, считываемый компьютером, по п.38, отличающийся тем, что одиночная непрерываемая операция представляет собой команду сохранения.
40. Носитель информации, считываемый компьютером, по п.38, отличающийся тем, что упомянутый способ для потока обновления дополнительно включает физическое удаление существующего элемента после записи указателя в базу данных.
41. Носитель информации, считываемый компьютером, по п.39, отличающийся тем, что команда сохранения записывает четыре байта в адрес памяти, размещенный на границе четырех байтов.
42. Носитель информации, считываемый компьютером, по п.39, отличающийся тем, что команда сохранения записывает восемь байтов в адрес памяти, размещенный на границе восьми байтов.
43. Носитель информации, считываемый компьютером, по п.38, отличающийся тем, что множество запросов на поиск принимают в одиночном пакете сети.
44. Носитель информации, считываемый компьютером, по п.38, отличающийся тем, что множество ответов по поиску передают в одиночном пакете сети.
45. Носитель информации, считываемый компьютером, по п.38, отличающийся тем, что ограничение доступа включает в себя блокировку базы данных.
46. Носитель информации, считываемый компьютером, по п.38, отличающийся тем, что ограничение доступа включает в себя взаимоблокировку.
47. Носитель информации, считываемый компьютером, по п.46, отличающийся тем, что взаимоблокировка включает в себя использование по меньшей мере одного семафора.
48. Носитель информации, считываемый компьютером, по п.47, отличающийся тем, что семафор является семафором мьютекса.
49. Носитель информации, считываемый компьютером, по п.38, отличающийся тем, что указатель на новый элемент записан в индекс поиска.
50. Носитель информации, считываемый компьютером, по п.49, отличающийся тем, что индекс поиска представляет собой TST.
51. Носитель информации, считываемый компьютером, по п.38, отличающийся тем, что указатель на новый элемент записан в запись данных в базе данных.
52. Способ поиска и параллельного обновления базы данных, заключающийся в том, что
создают поток обновления и множество потоков поиска,
назначают каждый из множества запросов на поиск, полученных через сеть, одному из множества потоков поиска,
для каждого потока поиска:
осуществляют поиск по базе данных в соответствии с назначенными запросами на поиск,
создают множество ответов по поиску, соответствующих назначенным запросам на поиск, и
посылают множество ответов по поиску через сеть, и
для потока обновления:
без ограничения доступа к базе данных для множества потоков поиска, записывают указатель на существующий элемент в базу данных с использованием одиночной непрерываемой операции.
53. Способ по п.52, отличающийся тем, что указатель содержит нулевой указатель.
54. Способ по п.52, отличающийся тем, что дополнительно для потока обновления физически удаляют существующий элемент после записи указателя в базу данных.
Текст
005646 Притязание на приоритет/перекрестная ссылка на связанные заявки Данная непредварительная заявка испрашивает приоритет предварительной патентной заявки США 60/330,842 от 1 ноября 2001 года, и предварительной патентной заявки США 60/365,169 от 19 марта 2002 года, полностью включенных в настоящее описание посредством ссылки. Область техники Настоящее изобретение относится к вычислительным системам, более конкретно, к способу и системе для обеспечения высокоскоростного поиска в базе данных с параллельным обновлением, без использования блокировок базы данных или средств управления доступом, для больших систем баз данных. Предшествующий уровень техники В условиях стремительного роста сети Интернет, разрешение (в службе разрешения имен - процесс определения адреса) при масштабировании службы имен доменов (DNS) для корневых серверов и общих серверов домена верхнего уровня (gTLD) при приемлемых ценах становится все в большей степени проблематичным. Корневой сервер (то есть, a.root-server.net) поддерживает и распределяет файл корневой зоны пространства имен Интернета для 12 вторичных корневых серверов, географически распределенных по всему миру (то есть b.root-server.net, с.root-server.net и т.д.), в то же время соответствующие сервера gTLD (то есть a.gtld-servers.net, b.gtld-servers.net, и т.д.) распределены аналогичным образом и поддерживают домены верхнего уровня (т.е. .com, .net, .org и т.д.). Постоянно увеличивающийся объем данных, связанный с неослабевающим увеличением интенсивности запросов, вынуждает полностью переосмыслить инфраструктуру аппаратных средств и программного обеспечения, необходимых для корневой и gTLD службы DNS в течение следующих нескольких лет. Стандартная инсталляция для одиночного сервера стандартных программных средств связывания "bind" уже не достаточна для потребностей корневого сервера и скоро не будет удовлетворять потребностям gTLD. В результате слияния коммутируемой телефонной сети общего пользования (PSTN) и Интернета, появились возможности для универсального, высокоэффективного механизма поиска, обеспечивающего возможности, обычно соответствующие Пунктам Управления Службами (SCP) в сети сигнализации SS7 телефонной сети PSTN, который предлагает новые, усовершенствованные службы, охватывающие PSTN и Интернет, включая службы Усовершенствованной Интеллектуальной Сети связи (AIN), передачи голоса по IP-протоколу (VOIP) и геолокации и т.д. Краткое описание чертежей Фиг. 1 - структурная схема системы, согласно варианту осуществления настоящего изобретения. Фиг. 2 - подробная структурная схема, иллюстрирующая структуру данных сообщения, согласно варианту осуществления настоящего изобретения. Фиг. 3 - подробная структурная схема, иллюстрирующая архитектуру структуры данных времени ожидания сообщения, согласно варианту осуществления настоящего изобретения. Фиг. 4 - подробная структурная схема, иллюстрирующая архитектуру структуры данных с не параллельным управлением, согласно варианту осуществления настоящего изобретения. Фиг. 5 - подробная структурная схема, иллюстрирующая архитектуру структуры данных с не параллельным управлением, согласно варианту осуществления настоящего изобретения. Фиг. 6 - подробная структурная схема, иллюстрирующая архитектуру структуры данных с не параллельным управлением, согласно варианту осуществления настоящего изобретения. Фиг. 7 - подробная структурная схема, иллюстрирующая архитектуру структуры данных с не параллельным управлением, согласно варианту осуществления настоящего изобретения. Фиг. 8 - подробная структурная схема, иллюстрирующая архитектуру структуры данных с не параллельным управлением, согласно варианту осуществления настоящего изобретения. Фиг. 9 - блок-схема верхнего уровня, поясняющая способ поиска и параллельного обновления базы данных без использования блокировок базы данных или средств управления доступом, согласно варианту осуществления настоящего изобретения. Подробное описание Варианты осуществления настоящего изобретения обеспечивают способ и систему для высокоскоростного поиска по базе данных с параллельным обновлением, без использования блокировок базы данных или средств управления доступом, для больших систем баз данных. В частности, через сеть связи может быть получено несколько запросов на поиск, может быть осуществлен поиск по базе данных, и через сеть связи может быть передано несколько ответов по поиску. В то время, как осуществляется поиск по базе данных, новая информация, полученная через сеть связи, может быть включена в базу данных посредством создания нового элемента, основанного на новой информации, и, без блокировки базы данных, записи в базу данных указателя на новый элемент с использованием одной непрерывной операции. На фиг. 1 показана структурная схема, иллюстрирующая систему, согласно варианту осуществления настоящего изобретения. В общем, система 100 может содержать большую резидентную базу данных, получать через сеть запросы на поиск и обеспечивать ответы по поиску. Например, система 100 может представлять собой симметричный многопроцессорный (SMP) компьютер, например, такой какEnterprise10000, производимый Sun Microsystems (Santa Clara, Калифорния) и т.д. Система 100 может также представлять собой многопроцессорный персональный компьютер, например, такой как CompaqProLliantML530 (имеющий два процессора Intel Pentium III 866 MHz), производимый компаниейHewlett-Packard (Palo Alto, Калифорния). Система 100 может также содержать многопроцессорную операционную систему, например, такую как IBM AIX 4, Sun Solaris 8 Operating Environment, Red HatLINUX 6.2, и т.д. Система 100 может получать через сеть 124 связи периодические обновления, которые могут параллельно включаться в базу данных. Варианты осуществления настоящего изобретения могут достигать очень высокой производительности обновления и поиска по базе данных посредством включения каждого обновления в базу данных без использования блокировок базы данных или средств управления доступом. В варианте осуществления система 100 может содержать по меньшей мере один процессор 102-1,подсоединенный к шине 101. Процессор 102-1 может содержать внутренний кэш (например, кэш L1, не изображен). Между процессором 102-1 и шиной 101 может быть резидентно размещен кэш 103-1 вторичной памяти (например, кэш L2, кэши L2/L3 и т.д.). В предпочтительном варианте осуществления система 100 может содержать множество процессоров 102-1102-Р, подсоединенных к шине 101. Между множеством процессоров 102-1102-Р и шиной 101 (например, архитектура сквозного просмотра) также может быть резидентно размещено множество кэшей 103-1103-Р вторичной памяти, или, в виде другого варианта, к шине 101 может быть подсоединен, по меньшей мере, один кэш 103-1 вторичной памяти (например, архитектура с предысторией). Система 100 может содержать память 104, например,такую как оперативное запоминающее устройство (ОЗУ), и т.д., подсоединенную к шине 101 для хранения информации и команд, которые должны выполняться множеством процессоров 102-1102-Р. Память 104 может хранить большую базу данных, например, для преобразования имен доменов Интернет в Интернет-адреса для преобразования имен или номеров телефонов в сетевые адреса, для обеспечения и обновления данных профиля абонента, для обеспечения и обновления данных присутствия пользователя, и т.д. Преимущественно, размер базы данных и количество преобразований в секунду могут быть очень большими. Например, память 104 может содержать по меньшей мере 64GB ОЗУ, и может иметь базу данных имен доменов в 500 М (то есть, 500 х 106) записей, базу данных абонентов в 500 М записей, базу данных мобильности номеров телефонов в 450 М записей и т.д. В возможной архитектуре 64-битной системы, например, такой как система, содержащая, по меньшей мере, один 64-битный процессор 102-1 с обратным порядком байтов, подсоединенный, по меньшей мере, к 64-битной шине 101, и 64-битную память 104, 8 байтовое значение указателя может быть записано в адрес (ячейки) памяти на границе 8-байтов (то есть, адрес памяти, делимый на восемь, или, например, 8N) с использованием одной непрерываемой операции. В основном, наличие кэша 103-1 вторичной памяти может просто задерживать запись 8-байтового указателя в память 104. Например, в одном варианте осуществления, кэш 103-1 вторичной памяти может представлять собой кэш сквозного просмотра,действующий в режиме сквозной записи так, чтобы одиночная команда сохранения 8-байтов могла перемещать восемь байтов данных из процессора 102-1 в память 104, без прерывания, и всего только за два такта системных часов. В другом варианте осуществления, кэш 103-1 вторичной памяти может представлять собой кэш сквозного просмотра, действующий в режиме обратной записи так, чтобы 8-байтовый указатель мог быть сначала записан в кэш 103-1 вторичной памяти, который затем, в более позднее время, может записать 8-байтовый указатель в память 104, например, при записи в память 104 строки кэша,в которой хранится 8-байтовый указатель, (то есть, например, когда сбрасывается в память определенная строка кэша, или полностью кэш вторичной памяти). В конечном счете, с точки зрения процессора 102-1, как только данные фиксируются на выходных контактах процессора 102-1, все 8 байтов данных записываются в память 104 в одной последовательной передаче, без прерываний которая может быть задержана эффектами кэша 103-1 вторичной памяти, если они имеют место. С точки зрения процессоров 102-2102-Р, как только данные фиксируются на выходных контактах процессора 102-1, все восемь байтов данных записываются в память 104 в одной последовательной передаче без прерываний, которая предписана протоколом согласованности кэша по кэшам 103-1 103-Р вторичной памяти, что может задержать запись в память 104, если имеет место. Однако, если 8-байтовое значение указателя записывается в невыровненную ячейку памяти 104, например, адрес памяти, который пересекает границу 8-байтов, то все восемь байтов данных не могут быть переданы из процессора 102-1 с использованием одиночной команды сохранения 8-байтов. Вместо этого,процессор 102-1 может выдать две разные и отдельные команды сохранения. Например, если адрес памяти начинается за четыре байта до границы 8 - байтов (например, 8N-4), то первая команда сохранения передает в память 104 четыре старших байта (например, 8N-4), в то время как вторая команда сохранения передает в память 104 четыре младших байта (например, 8N) . Существенно, что между этими двумя отдельными командами сохранения, в процессоре 102-1 может иметь место прерывание, или, процессор 102-1 может освободить управление шиной 101 для другого компонента системы (например, процессора 102-Р, и т.д.). Следовательно, значение указателя, резидентно находящееся в памяти 104, будет недействительным, пока процессор 102-1 не сможет завершить вторую команду сохранения. Если другой ком-2 005646 понент начинает одиночное считывание памяти без прерываний в этой ячейке памяти, то недействительное значение будет возвращено как предполагаемое действительным. Аналогично, новое 4-байтовое значение указателя может быть записано в адрес памяти, делимый на четыре (например, 4N), с использованием одиночной операции без прерываний. Следует отметить, что в примере, описанном выше, 4-байтовое значение указателя может быть записано в ячейку памяти 8N-4 с использованием одиночной команды сохранения. Безусловно, если 4-байтовое значение указателя записывается в ячейку, пересекающую границу 4-байтов, например, 4N-2, то все четыре байта данных не могут быть переданы из процессора 102-1 с использованием одиночной команды сохранения, и значение указателя, резидентно размещенное в памяти 104, может в течение некоторого периода времени быть недействительным. Система 100 также может содержать постоянное запоминающее устройство (ПЗУ) 106, или другие статические запоминающие устройства, подсоединенные к шине 101 для хранения статической информации и команд для процессора 102-1. К шине 101 для хранения информации и команд может быть подсоединено запоминающее устройство 108, такое как магнитный или оптический диск. Система 100 также может содержать устройство 110 отображения (например, монитор на жидких кристаллах LCD (ЖДК и устройство 112 ввода данных (например, клавиатуру, мышь, трекбол и т.д.), подсоединенное к шине 101. Система 100 может содержать несколько сетевых интерфейсов 114-1114-O, которые могут передавать и принимать электрические, электромагнитные или оптические сигналы, несущие потоки цифровых данных, представляющие различные виды информации. В варианте осуществления сетевой интерфейс 114-1 может быть подсоединен к шине 101 и к локальной сети LAN (ЛС) 122, в то же время сетевой интерфейс 114-O, может быть подсоединен к шине 101 и глобальной сети WAN (ГС) 124. Множество сетевых интерфейсов 114-1114-O могут поддерживать разные сетевые протоколы, включая, например, GigabitEthernet (например, IEEE Стандарт 802.3-2002, изданный в 2002), Fiber Channel (например, ANSI Стандарт X.3230-1994, изданный в 1994) и т.д. К ЛС 122 и ГС 124 может быть подсоединено множество сетевых компьютеров 120-1120-N. В одном варианте осуществления ЛС 122 и ГС 124 могут быть физически отдельными сетями, в то же время в другом варианте осуществления ЛС 122 и ГС 124 могут быть(соединены) через сетевой шлюз или маршрутизатор (для ясности не изображены). В качестве другого варианта, ЛС 122 и ГС 124 может быть одной и той же сетью. Как отмечено выше, система 100 может обеспечивать службы разрешения DNS. В варианте осуществления для разрешения DNS службы разрешения DNS в основном могут быть разделены между функциями транспортировки по сети и поиска данных. Например, система 100 может быть механизмом поиска (LUE) для сервера, оптимизированным для поиска данных по большим наборам данных, в то же время множество сетевых компьютеров 120-1120-N могут представлять собой множество механизмов протокола (РЕ) клиента, оптимизированными для сетевой обработки и транспортировки. LUE может быть мощным многопроцессорным сервером, который хранит в памяти 104 весь набор записей DNS, способствуя быстродействующему, высокопроизводительному поиску и обновлению данных. В другом варианте осуществления службы разрешения DNS могут быть обеспечены несколькими мощными многопроцессорными серверами или LUE, каждый из которых хранит в памяти подмножество всего набора записей DNS, способствуя быстродействующему, высокопроизводительному поиску и обновлению данных. Напротив, несколько РЕ могут быть общими узко специализированными устройствами на базе PC,на которых исполняется эффективная многозадачная операционная система (например, Red Hat LINUX(D 6.2, которые минимизируют транспортную нагрузку обработки сети на LUE для максимизации доступных ресурсов для разрешения DNS. Устройства РЕ могут обрабатывать нюансы протокола DNS проводной линии связи, реагировать на недействительные запросы DNS и мультиплексировать действительные запросы DNS в LUE через ЛС 122. В другом варианте осуществления с использованием множестваLUE, хранящих подмножества записей DNS, РЕ могут определять, какое устройство LUE должно получить каждый действительный запрос DNS, и мультиплексировать действительные запросы DNS в соответствующий LUE. Количество РЕ для одного LUE может определяться, например, количеством запросов DNS, которое должно обрабатываться в секунду, и рабочими характеристиками конкретной системы. Для определения отношений соответствия и режимов также могут использоваться другие показатели. В принципе, могут поддерживаться другие крупномасштабные варианты осуществления большого объема, основанные на запросах, включающие в себя, например, разрешение номеров телефонов, обработку сигнализации SS7, геолокационное определение, установление соответствия номер телефона абонент, определение местоположения и присутствия абонента и т.д. В варианте осуществления центральный сервер 140-1 оперативной обработки транзакций (OLTP) может быть подсоединен к ГС 124 и получать из разных источников добавления, изменения и удаления(то есть трафик обновления) для базы данных 142-1. OLTP сервер 140-1 может передавать обновления через ГС 124 в систему 100, которая содержит локальную копию базы данных 142-1. OLTP сервер 140-1 может быть оптимизирован для обработки графика обновления в различных форматах и протоколах,включая, например, Протокол Передачи Гипертекстовых файлов (HTTP), Протокол Регистратора Записи(RRP), Наращиваемый Протокол Инициализации (ЕРР), Систему Управления Службами/ Механизированный Общий Интерфейс (MGI) 800, и другие оперативные протоколы инициализации. СовокупностьLUE только для чтения может быть развернута в архитектуре концентратор-луч (линия, идущая от центра к периферии) для обеспечения возможности высокоскоростного поиска в совокупности с объемными, добавочными обновлениями из OLTP сервера 140- 1. В альтернативном варианте осуществления данные могут быть распределены по множеству OLTP серверов 140-1140-S, каждый из которых может быть подсоединен к ГС 124. OLTP серверов 140-1140-S могут получать из разных источников добавления, изменения и удаления (то есть трафик обновления) для соответствующих им баз данных 142-1142-S (не изображены для ясности) . OLTP сервера 140-1140-S могут передавать обновления через ГС 124 в систему 100, которая может содержать копии баз данных 142-1142-S, другие динамически-создаваемые данные и т.д. Например, в варианте осуществления для геолокации OLTP сервера 140-1140-S могут получать график обновления от групп удаленных датчиков. В другом альтернативном варианте осуществления множество сетевых компьютеров 120-1120-N также может получать через ГС 124 или ЛС 122 добавления, изменения и удаления (то есть трафик обновления) из разных источников. В этом варианте осуществления множество сетевых компьютеров 120-1120-N может передавать в систему 100 обновления, а также запросы. В варианте осуществления разрешения DNS каждый РЕ (например, каждый из множества сетевых компьютеров 120-1120-N) может комбинировать, или мультиплексировать, различные сообщения запросов DNS, полученные через глобальную сеть связи (например, ГС 124), в одиночный Суперпакет Запроса и через локальную сеть связи (например, ЛС 122) передавать Суперпакет Запроса в LUE (например, систему 100). LUE может комбинировать, или мультиплексировать, несколько ответов на сообщения запросы DNS в одиночный СуперПакет Ответа и передавать Суперпакет Ответа через локальную сеть связи соответствующему РЕ. В основном, максимальный размер Суперпакета Ответа или Запроса может быть ограничен максимальным блоком передачи (MTU) физического сетевого уровня (например,GigabitEthernet). Например, стандартные размеры сообщения запроса и ответа DNS, не превышающие 100 байтов и 200 байтов, соответственно, позволяют мультиплексировать более 30 запросов в одиночный Суперпакет Запроса, а также мультиплексировать более 15 ответов в одиночный Суперпакет Ответа. Однако, в одиночный Суперпакет Запроса может быть включено меньшее количество запросов (например,20 запросов), чтобы избежать переполнения MTU при ответе (например, в 10 ответов). Для больших размеров MTU, количество мультиплексированных запросов и ответов может быть, соответственно, увеличено. Каждый многозадачный РЕ может иметь входящий поток и исходящий поток для управления запросами и ответами DNS, соответственно. Например, входящий поток может демаршалинговать компоненты запроса DNS из входящих пакетов запроса DNS, полученных через глобальную сеть связи, и мультиплексировать несколько миллисекунд запросов в одиночный Суперпакет Запроса. Затем входящий поток может передать Суперпакет Запроса через ЛС в LUE. Обратно, исходящий поток может получать Суперпакет Ответа из LUE, демультиплексировать содержащиеся в нем ответы и маршалинговать различные поля в действительный ответ DNS, который затем может быть передан через глобальную сеть связи. В основном, как отмечено выше, могут поддерживаться другие варианты осуществления большого объема, основанные на запросах. В варианте осуществления Суперпакет Запроса может также содержать информацию о состоянии,соответствующую каждому запросу DNS, например, такую как исходный адрес, тип протокола и т.д.LUE может включать Суперпакет Ответа информацию о состоянии и соответствующие ответы DNS. Затем каждый РЕ может формировать и возвращать действительные сообщения ответа DNS с использованием информации, переданной из LUE. Следовательно, каждый РЕ может, преимущественно, функционировать как устройство, не меняющее своего состояния в процессе исполнения, то есть действительные ответы DNS могут быть сформированы из информации, содержащейся в Суперпакете Ответа. В основном, LUE может возвращать Суперпакет Ответа в РЕ, из которого исходил входящий Суперпакет, однако, очевидно, что возможны другие варианты. В альтернативном варианте осуществления каждый РЕ может поддерживать информацию о состоянии, соответствующую каждому запросу DNS и включать ссылку, или дескриптор, на информацию о состоянии Суперпакет Запроса. LUE может включать Суперпакет Ответа ссылки на информацию о состоянии и соответствующие ответы DNS. Затем каждый РЕ может формировать и возвращать действительные сообщения ответа DNS с использованием ссылок на информацию о состоянии, переданных изLUE, а также поддерживаемой им информации о состоянии. В этом варианте осуществления LUE может возвращать Суперпакет Ответа в РЕ, из которого исходил входящий Суперпакет. На фиг.2 представлена подробная структурная схема, иллюстрирующая структуру данных сообщения, согласно варианту осуществления настоящего изобретения. В основном, сообщение 200 может содержать заголовок 210, имеющий множество порядковых номеров 211-1211-S и множество счетчиков 212-1212-S сообщений и полезную нагрузку 215 данных. В варианте осуществления разрешения DNS сообщение 200 может использоваться для Суперпакетов Запроса и Суперпакетов Ответа. Например, Суперпакет 220 Запроса может содержать заголовок 230,имеющий множество порядковых номеров 231-1231-S и множество счетчиков 232-1232-S сообщений и полезную нагрузку 235 данных, содержащую множество запросов 236-1236 - Q DNS, накоп-4 005646 ленных РЕ за предварительно определенный период времени, например, за несколько миллисекунд. В одном варианте осуществления каждый запрос 236-1236-Q DNS может содержать информацию о состоянии, хотя в альтернативном варианте осуществления каждый запрос 236-1236-Q DNS может содержать дескриптор для информации о состоянии. Аналогично, Суперпакет 240 Ответа может содержать заголовок 250, имеющий множество порядковых номеров 251-1251-S и множество счетчиков 252-1252-S сообщений и полезную нагрузку 255 данных, содержащую ответы 256-1256-R DNS, примерно соответствующие множеству запросов DNS,содержащихся внутри Суперпакета 220 Запроса. В одном варианте осуществления каждый ответ 256-1256-R DNS может содержать информацию о состоянии, сопоставленную соответствующему запросуDNS, в то же время в альтернативном варианте осуществления каждый ответ 256-1256-R DNS может содержать дескриптор для информации о состоянии, сопоставленной соответствующему запросу DNS. Иногда, общий размер соответствующих ответов DNS может превышать размер полезной нагрузки 255 данных Суперпакета 240 Ответа. Это переполнение может быть ограничено, например, одним ответом,то есть, ответом, соответствующим последнему запросу, содержащемуся внутри Суперпакета 220 Запроса. Вместо передачи дополнительного Суперпакета 240 Ответа, содержащего только один ответ, предпочтительно, ответ, вызывающий переполнение, может быть включен в следующий Суперпакет 240 Ответа, соответствующий следующему Суперпакету Запроса. Преимущественно, заголовок 250 может содержать соответствующую информацию для определения границ для условия переполнения. В пиковых условиях обработки при переполнении в следующий Суперпакет Ответа может переходить более одного ответа. Например, в Суперпакете 240 Ответа заголовок 250 может содержать, по меньшей мере, два порядковых номера 251-1 и 251-2 и, по меньшей мере, два счетчика 252-1 и 252-2 сообщений, сгруппированных в виде двух пар дополнительных полей. Хотя может существовать "S" пар порядковых номеров и счетчиков сообщений, обычно, S является небольшим числом, таким как, например, 2, 3, 4 и т.д. Следовательно, заголовок 250 может содержать порядковый номер 251-1, парный с счетчиком 252-1 сообщений, порядковый номер 251-2, парный с счетчиком 252-2 сообщений, и т.д. В основном, счетчик 252-1 сообщений может отражать количество ответов, содержащихся внутри полезной нагрузки 255 данных,которые соответствуют порядковому номеру 251-1. В варианте осуществления порядковым номером 251-1 может быть двух-байтовое поле, в то же время счетчиком 252-1 сообщений может быть однобайтовое поле. В более частном примере полезная нагрузка 235 данных из Суперпакета 220 Запроса может содержать семь запросов DNS (как изображено на Фиг.2). В одном варианте осуществления порядковый номер 231-1 может быть установлен на уникальное значение (например, 1024) и счетчик 232-1 сообщений может быть установлен на семь, в то же время порядковый номер 231-2 и счетчик 232-2 сообщений могут быть установлены на нуль. В другом варианте осуществления заголовок 230 может содержать только один порядковый номер и один счетчик сообщений, например, порядковый номер 231-1 и счетчик сообщений 232-1, установленные на 1024 и семь, соответственно. Обычно, Суперпакет 220 Запроса может содержать все запросы, соответствующие конкретному порядковому номеру. Полезная нагрузка 255 данных Суперпакета 240 Ответа может содержать семь соответствующих ответов DNS (как указано на Фиг.2). В указанном примере заголовок 250 может содержать информацию,подобную информации Суперпакета 220 Запроса, то есть, порядковый номер 251-1, установленный на то же уникальное значение (то есть, 1024), счетчик 252-1 сообщений, установленный на семь, и порядковый номер 252-2 и счетчик 252-2 сообщений, установленные на нуль. Однако, в другом примере, полезная нагрузка данных 255 Суперпакета 240 Ответа может содержать только пять соответствующих ответовDNS, и при этом счетчик 252-1 сообщений может быть установлен на пять. Оставшиеся два ответа, соответствующие порядковому номеру 1024, могут быть включены в следующий Суперпакет 240 Ответа. Следующий Суперпакет 240 Запроса может содержать другой порядковый номер (например, 1025) и по меньшей мере один запрос DNS, так что следующий Суперпакет 240 Ответа может содержать два предыдущих ответа, соответствующих порядковому номеру 1024, а также, по меньшей мере, один ответ,соответствующий порядковому номеру 1025. В этом примере заголовок 250 следующего Суперпакета 240 Ответа может содержать порядковый номер 251-1, установленный на 1024, счетчик 252-1 сообщений, установленный на два, порядковый номер 251-2, установленный на 1025, и счетчик 252-2 сообщений, установленный на единицу. Следовательно, Суперпакет 240 Ответа может содержать всего три ответа, соответствующих трем запросам, содержащимся в двух различных Суперпакетах Запроса. На фиг. 3 представлена подробная структурная схема, иллюстрирующая архитектуру структуры данных времени ожидания сообщения, согласно варианту осуществления настоящего изобретения. Структура 300 данных времени ожидания сообщения может содержать информацию, в основном соответствующую передаче и получению сообщения 200. В варианте осуществления разрешения DNS структура 300 данных времени ожидания сообщения может содержать информацию о времени ожидания относительно Суперпакетов Запроса и Суперпакетов Ответа; такая информация о времени ожидания может быть организована в формате таблицы, индексированной в соответствии с значением порядкового номера (например, индекс 301). Например, количество строк N в структуре 300 данных времени ожида-5 005646 ния сообщения может быть равным общему количеству уникальных порядковых номеров, как иллюстрируется, в основном, элементами 310, 320 и 330 таблицы. В варианте осуществления порядковые номера заголовка Суперпакета могут иметь двух-байтовую длину и определять диапазон уникальных порядковых номеров от нуля до 216-1 (то есть 65535). В этом случае, N может быть равным 65536. Информация о времени ожидания может содержать Временную метку 302 Запроса, Счетчик 303 запросов Запроса,Временную метку 304 Ответа, Счетчик 305 ответов Ответа, и Счетчик 306 сообщений Ответа. В альтернативном варианте осуществления информация о времени ожидания может также содержать Временную метку Первоначального Ответа (не изображена). В одном примере элемент 320 таблицы иллюстрирует информацию о времени ожидания для Суперпакета 220 Запроса, имеющего один порядковый номер 231-1, равный 1024. Временная метка 302 Запроса может указывать, когда данный конкретный Суперпакет Запроса был передан в LUE. Счетчик 303 запросов Запроса может указывать количество запросов, содержащихся внутри данного конкретного Суперпакета Запроса. Временная метка 304 Ответа может указывать, когда Суперпакет Ответа, имеющий порядковый номер, равный 1024, был получен в РЕ (например, в сетевом компьютере 120-N) и может обновляться, если в РЕ было получено более одного Суперпакета Ответа. Счетчик 305 ответов Ответа может указывать общее количество ответов, содержащихся внутри всех полученных Суперпакетов Ответа, соответствующих указанному порядковому номеру (то есть 1024). Счетчик 306 Сообщений Ответа может указывать количество Суперпакетов Ответа, поступивших в РЕ, имеющих данный порядковый номер (то есть, 1024). Ответы на запросы, содержащиеся внутри данного конкретного Суперпакета Запроса, могут быть разбиты по нескольким Суперпакетами Ответа, в этом случае при получении каждого из дополнительных Суперпакетов Ответа, Временная метка 304 Ответа, Счетчик 305 ответов Ответа, и Счетчик 306 Сообщений Ответа могут обновляться. В альтернативном варианте осуществления Временная метка Первоначального Ответа может указывать, когда в РЕ был получен первый Суперпакет Ответа, содержащий ответы для указанного порядкового номера (то есть, 1024). В этом варианте осуществления, при получении дополнительных (то есть второго и последующих) Суперпакетов Ответа, Временная метка 304 Ответа может обновляться. Из информации о времени ожидания, содержащейся в структуре 300 данных времени ожидания сообщения, могут быть определены разные важные показатели времени ожидания. Например, простая перекрестная проверка между Счетчиком 303 запросов Запроса и Счетчиком 305 ответов Ответа для заданного индекса 301 (то есть порядкового номера) может показать количество отсутствующих ответов. Эта разница может указывать на количество запросов, опущенных LUE по неизвестной причине. Сравнение Временной метки 302 Запроса и Временной метки 304 Ответа может показать, насколько хорошо может работать конкретная комбинация PE/LUE при текущей загрузке сообщений. Разница между текущим порядковым номером Суперпакета Запроса и текущим порядковым номером Суперпакета Ответа может быть связана с реакционной способностью LUE; например, чем больше разница, тем ниже эта рабочая характеристика. Счетчик 306 Сообщений Ответа может указывать количество Суперпакетов Ответа, используемых для каждого Суперпакета Запроса, и может быть значим для анализа графика разрешенияDNS. При увеличении времени ожидания запросов и ответов, перемещающихся между РЕ и LUE, РЕ могут уменьшить количество пакетов запроса DNS, обрабатываемых системой. В основном, LUE может выполнять многопоточный поиск по входящим, мультиплексированным Суперпакетам Запроса, и может объединять ответы в исходящие, мультиплексированные Суперпакеты Ответа. Например, LUE может порождать один поток поиска, или процесс, для каждого активного РЕ и направлять все входящие Суперпакеты Запроса из этого РЕ в данный поток поиска. LUE может порождать управляющий поток, или процесс, для управления совокупностью РЕ, для потоков поиска, а также потока обновления, или процесса, для обновления базы данных, размещенной в памяти 104. Каждый поток поиска может извлекать из входящего Суперпакета Запроса запросы на поиск, выполнять разные поиски, создавать исходящий Суперпакет Ответа, содержащий ответы по поиску и передавать Суперпакет соответствующему РЕ. Поток обновления может получать обновления для базы данных, из OLTP 140-1,и включать в базу данных новые данные. В альтернативном варианте осуществления множество сетевых компьютеров 120-1120-N могут передавать обновления системе 100. Эти обновления могут включаться, например, во входящий поток сообщений Суперпакета Запроса. Соответственно, на основании протокола Суперпакета, LUE может расходовать менее 15% ресурсов процессора на сетевую обработку, вследствие этого существенно увеличивая пропускную способность запросов на поиск. В одном варианте осуществления IBM 8-way M80 может поддерживать скорости поиска от 180k до 220k запросов в секунду (qps), в то время как IBM 24-way S80 может поддерживать от 400k до 500k qps. Удвоение скоростей поиска, то есть, до 500k и 1 М qps, соответственно, просто требует вдвое большее количество аппаратных средств, то есть, например, два LUE с обслуживающими их РЕ. В другом варианте осуществления многопроцессорный персональный компьютер на двух процессорах PENTIUM III 866 МГц, исполняющий Red Hat LINUX 6.2, может поддерживать скорости обновления порядка 100 К/sec. Безусловно, рост эффективности аппаратных средств также повышает скорости обновления и поиска, соответствующие вариантам осуществления настоящего изобретения, и по мере того как фирмы - изготовители заменяют указанные многопроцессорные компьютеры, например, уст-6 005646 ройствами с более высоким быстродействием, поддерживаемые скорости поиска и обновления могут соразмерно увеличиваться. В принципе, система 100 не ограничена архитектурой клиента или сервера, и варианты осуществления настоящего изобретения не ограничены какой-либо конкретной комбинацией аппаратных средств и/или программного обеспечения. На фиг. 4 представлена структурная схема, иллюстрирующая общую архитектуру базы данных, согласно варианту осуществления настоящего изобретения. В этом варианте осуществления база данных 400 может содержать, по меньшей мере, одну таблицу, или группу записей 401 базы данных и, по меньшей мере, один соответствующий индекс 402 поиска с указателями (индексы, указывающие смещения байтов, и т.д.) на индивидуальные записи внутри группы записей 401 базы данных. Например, указатель 405 может осуществлять ссылку на запись 410 базы данных. В одном варианте осуществления база данных 400 может содержать, по меньшей мере, одну хэштаблицу 403 в качестве индекса поиска с указателями (индексы, указывающие смещения байтов, и т.д.) внутри таблицы или группы записей 401 базы данных. Хэш-функция может отображать поисковый ключ в целочисленное значение, которое затем может использоваться в качестве индекса в хэш-таблице 403. Поскольку в одно целочисленное значение может быть отображено более одного поискового ключа, то могут создаваться хэш-области памяти с использованием однонаправленного списка указателей цепочки хэширования. Например, каждый элемент в хэш-таблице 403 может содержать указатель на первый элемент хэш-области памяти, и каждый элемент хэш-области памяти может содержать указатель цепочки хэширования на следующий элемент, или запись базы данных в связанном списке. Преимущественно,указатель цепочки хэширования может требоваться только для элементов, или записей базы данных, которые осуществляют ссылку на последующий элемент в хэш-области памяти. Хэш-таблица 403 может содержать массив 8-байтовых указателей на индивидуальные записи 401 базы данных. Например, хэш-указатель 404 внутри хэш-таблицы 403 может осуществлять ссылку на запись 420 базы данных, как на первый элемент внутри хэш-области памяти. Запись 420 базы данных может содержать указатель 424 цепочки хэширования, который может осуществлять ссылку на следующий элемент, или запись базы данных, в хэш области памяти. Запись 420 базы данных также может содержать длину 421 данных и соответствующие данные 422 фиксированной или переменной длины. В одном варианте осуществления может присоединяться символ 423 нуля, указывающий окончание данных 422. Дополнительно, запись 420 базы данных может содержать указатель 425 на данные, который может осуществлять ссылку на другую запись базы данных или внутри группы записей 401 базы данных или внутри другой таблицы или группы записей базы данных (не изображены), в которых могут быть размещены дополнительные данные. Система 100 может использовать разные известные алгоритмы для поиска по указанной архитектуре структуры данных для заданного условия или поискового ключа. В основном, поиск по базе данных 400 может осуществляться посредством множества процессов поиска, или потоков, выполняющихся, по меньшей мере, на одном из множества процессоров 102-1102-Р. Однако, изменения в базе данных 400 в целом не могут быть выполнены потоком (или потоками) обновления, пока на период времени, необходимый для добавления, изменения или удаления информации внутри базы данных 400, не предотвращен доступ к базе данных 400 для потока(ов) поиска. Например, для изменения записи 430 базы данных внутри базы данных 400, группа записей 401 базы данных может быть блокирована потоком обновления,чтобы предотвратить доступ потоков поиска к базе данных 400, пока поток обновления изменяет информацию внутри записи 430 базы данных. Существует много известных механизмов для блокировки базы данных 400 с целью предотвращения доступа для поиска, включая использование спин-блокировок, семафоров, мьютексов и т.д. Дополнительно, существующие коммерческие базы данных обеспечивают специальные команды для полной или частичной блокировки базы данных 400, например, команда заблокировать таблицу в Базе данных Oracle 8, созданной корпорацией Oracle (Редвуд Шорез, Калифорния) и т.д. На фиг. 5 представлена структурная схема, иллюстрирующая общую архитектуру базы данных, согласно другому варианту осуществления настоящего изобретения. В этом варианте осуществления база данных 500 может содержать высоко оптимизированный главный файл 510 кадра (отображения статического состояния набора данных), разрешенный только для чтения, и файл 520 предыстории. Главный файл 510 кадра может содержать, по меньшей мере, одну таблицу, или группу записей 511 базы данных и, по меньшей мере, один соответствующий индекс 512 поиска с указателями (индексы, указывающие смещения байтов, и т.д.) на индивидуальные записи группе записей 511 базы данных. В другом варианте,главный файл 510 кадра может содержать, по меньшей мере, одну хэш-таблицу 513 в качестве индекса поиска с указателями (индексы, указывающие смещения байтов, и т.д.) в таблице или группе записей 511 базы данных. Аналогично, файл 520 предыстории может содержать, по меньшей мере, две таблицы или группы записей базы данных, включая записи 521 добавления в базу данных и записи 531 удаления из базы данных. Могут быть обеспечены соответствующие индексы 522 и 532 поиска с указателями (индексы, указывающие смещения байтов, и т.д.) на индивидуальные записи в записях 521 добавления в базу данных и в записях 531 удаления из базы данных. В другом варианте, файл 520 предыстории может содержать хэш-таблицы 523 и 533 в качестве индексов поиска, с указателями (индексы, указывающие сме-7 005646 щения байтов, и т.д.) на записи 521 добавления в базу данных и на записи 531 удаления из базы данных,соответственно. Система 100 может использовать разные известные алгоритмы для поиска по указанной архитектуре структуры данных для заданного условия или поискового ключа. В типичном примере файл 520 предыстории может содержать все последние изменения данных, и по нему может быть осуществлен поиск до главного файла 510 кадра, разрешенного только для чтения. Если поисковый ключ найден в файле 520 предыстории, то ответ возвращается без обращения к файлу 510 кадра, но если ключ не найден, то может быть осуществлен поиск по файлу 510 кадра. Однако, когда файл 520 предыстории больше не согласуется в памяти 104 с файлом кадра 510, то скорости запросов на поиск существенно падают, например, от 10 до 50 раз, или больше. Следовательно, чтобы избежать или минимизировать любое падение скоростей запросов на поиск, файл 510 кадра может периодически обновляться, или повторно создаваться для включения всех добавлений, удалений и изменений, содержащихся в файле 520 предыстории. Данные в файле 510 кадра физически не изменяются, но добавляются, изменяются или удаляются логически. Например, данные в файле 510 кадра могут быть удалены, или логически "забыты", посредством создания соответствующий записи удаления в записях 531 удаления из базы данных и записи указателя на запись удаления для соответствующей ячейки в хэш-таблице 533. Данные в файле 510 кадра могут быть логически изменены посредством копирования записи данных из файла 510 кадра в новую запись данных в записях 521 добавления в базу данных, изменения данных внутри нового входа (записи), и затем записи указателя для нового входа в соответствующую хэш-таблицу (например, хэш-таблица 522) или указателя цепочки в записях 521 добавления в базу данных. Аналогично, данные в файле 510 кадра могут быть логически добавлены в файл 510 кадра посредством создания новой записи данных в записях 521 добавления в базу данных и затем записи указателя для нового входа в соответствующую хэштаблицу (например, хэш-таблица 522) или указателя цепочки в записях 521 добавления в базу данных. В варианте осуществления разрешения DNS, например, файл 510 кадра может содержать данные имен доменов и данные сервера доменных имен, организованные в виде отдельных таблиц данных, или блоков, с отдельными индексами поиска (например, 511-1, 511-2, 512-1, 512-2, 513-1, 513-2, и т.д., для ясности не изображены). Аналогично, файл 520 предыстории может содержать добавления и изменения для данных имен доменов и для данных сервера доменных имен, а также удаления для данных имен доменов и для данных сервера доменных имен (например, 521-1, 521-2, 522-1, 522-2, 523-1, 523-2, 531-1,531-2, 532-1, 532-2, 533-1, 533-2 и т.д., для ясности не изображены). На фиг. 6 представлена подробная структурная схема, иллюстрирующая архитектуру структуры данных с не параллельным управлением, согласно варианту осуществления настоящего изобретения. В основном, база данных 600 может быть организована в единое представление данных с возможностью осуществления поиска. Обновления набора данных могут включаться в базу данных 600 постоянно, и для релевантных записей базы данных удаления или изменения могут выполняться физически для освобождения пространства в памяти 104, например, для последующих добавлений или изменений. Единое представление с возможностью осуществления поиска очень хорошо масштабируется для больших размеров набора данных и высоких скоростей обновления и поиска, и устраняет необходимость периодического повторного создания, распространения и перезагрузки файлов кадра для множества компьютеров механизма поиска. В варианте осуществления разрешения DNS, например, база данных 600 может содержать данные 610 имен доменов и данные 620 сервера доменных имен. Данные 610 имен доменов и данные 620 сервера доменных имен могут содержать индексы поиска с указателями (индексы, указывающие смещения байтов, и т.д.) на блоки записей переменной длины. Как описано выше, хэш-функция может отображать поисковый ключ в целочисленное значение, которое затем может использоваться в качестве индекса в хэш-таблице. Аналогично, для каждого индекса хэш-таблицы могут быть созданы хэш-области памяти с использованием однонаправленного списка указателей цепочки хэширования. Данные 610 имен доменов могут содержать, например, хэш-таблицу 612 в качестве индекса поиска и блок записей 611 имен доменов переменной длины. Хэш-таблица 612 может содержать массив 8-байтовых указателей на индивидуальные записи 611 имен доменов, например, таких как указатель 613, осуществляющий ссылку на запись 620 имени домена. Запись 620 имени домена переменной длины может содержать, например, смещение 621 следующей записи, длину 622 имени, нормированное имя 623, указатель 624 цепочки (то есть, например, указывающий на следующую запись в цепочке хэширования), количество 625 серверов доменных имен и указатель 626 сервера доменных имен. Размер указателя 624 цепочки и указателя 626 сервера доменных имен может быть оптимизирован для отражения требуемого размера блока для каждого конкретного типа данных, например, восемь байтов для указателя 624 цепочки и четыре байта для указателя 626 сервера доменных имен. Данные 630 серверов доменных имен могут содержать, например, хэш-таблицу 632 в качестве индекса поиска и блок записей 631 сервера доменных имен переменной длины. Хэш-таблица 632 может содержать массив 4-байтовых указателей на индивидуальные записи 631 серверов доменных имен, например, такие как указатель 633, ссылающийся на запись 640 сервера доменных имен. Запись 640 сервера доменных имен переменной длины может содержать, например, смещение 641 следующей записи,-8 005646 длину 642 имени, нормированное имя 643, указатель 644 цепочки (то есть, например, указывающий на следующую запись в цепочке хэширования), количество сетевых адресов 645 сервера доменных имен,длину 646 адреса сервера доменных имен и сетевой адрес 647 сервера доменных имен, который может быть, например, сетевым адресом Интернет Протокола (IP). В основном, сетевые адреса сервера доменных имен могут храниться в формате ASCII (Американский Стандартный Код Обмена Информацией,например, ISO-14962-1997, ANSI-X3.4-1997 и т.д.) или в двоичном формате; в этом примере, длина 646 сетевого адреса сервера доменных имен указывает, что сетевой адрес 647 сервера доменных имен хранится в двоичном формате (то есть, четыре байта). Размер указателя 644 цепочки также может быть оптимизирован для отражения требуемого размера блока данных сервера доменных имен, например, 4 байта. В основном, индексы поиска, такие как хэш-таблицы, и записи данных переменной длины могут быть структурированы так, чтобы 8-байтовые указатели в памяти были размещены на границах 8-байтов. Например, хэш-таблица 612 может содержать непрерывный массив 8-байтовых указателей на записи 611 имен доменов и может храниться в адресе памяти, делимом на восемь (то есть границе 8-байтов, или 8N). Аналогично, индексы поиска, такие как хэш-таблицы, и записи данных переменной длины могут быть структурированы так, чтобы 4-байтовые указатели в памяти были размещены на границах 4-байтов. Например, хэш-таблица 632 может содержать непрерывный массив 4-байтовых указателей на записи 631 серверов доменных имен и может храниться в адресе памяти, делимом четыре (то есть границе 4-байтов,или 4N). Следовательно, изменения в базе данных 600 могут заключаться в обновлении указателя в выровненном адресе памяти с использованием одиночной непрерываемой операции, включающей, например, запись нового указателя в индекс поиска, такой как хэш-таблица, или запись нового указателя цепочки хэширования в запись данных переменной длины. На фиг. 7 представлена подробная структурная схема, иллюстрирующая архитектуру структуры данных с не параллельным управлением, согласно варианту осуществления настоящего изобретения. В основном, база данных 700 также может быть организована в единое представление данных с возможностью осуществления поиска. Обновления набора данных могут постоянно включаться в базу данных 700,и для релевантных записей базы данных удаления или изменения могут выполняться физически для освобождения пространства в памяти 104, например, для последующих добавлений или изменений. Единое представление с возможностью осуществления поиска очень хорошо масштабируется для больших размеров набора данных и высокой скорости обновления и поиска и устраняет необходимость в периодическом повторном создании, распространении и перезагрузке файлов кадра для множества компьютеров механизма поиска. Возможны многие разные способы организации структур данных. Возможный способ организации может использовать альтернативный индекс поиска по отношению к хэш-таблицам для упорядоченного последовательного доступа к записям данных, такой как тернарное дерево поиска, или TST, которое комбинирует возможности двоичных деревьев поиска и подходы цифрового поиска. В приложениях,основанных на текстовых данных, таких как например, кто есть кто, разрешение имени домена с использованием Расширений Защиты DNS (Запрос на Комментарии Проблемной Группы Проектирования Интернет: 2535), и т.д. деревья TST, преимущественно, минимизируют количество операций сравнения,необходимых для выполнения, особенно в случае неудачи при поиске, и могут выдавать показатели эффективности поиска, превышающие соответствующие показатели для реализации механизма поиска с хешированием. Дополнительно, деревья TST могут обеспечивать также расширенные возможности поиска текста, например, такие как поиск с групповым символом (джокером), который может быть полезен в приложениях поиска текста, таких как, например, кто есть кто, разрешения имен доменов, поиска содержимого Интернет и т.д. В одном варианте осуществления TST может содержать последовательность узлов, связанных вместе в иерархической зависимости. Корневой узел может быть размещен на вершине дерева, зависимые узлы-потомки и связи могут формировать ветви (условные переходы), а концевые узлы могут завершать конец каждой ветви. Каждому концевому узлу может соответствовать конкретный поисковый ключ, и каждый узел на пути к концевому узлу может содержать одиночный последовательный элемент этого ключа. Каждый узел в дереве содержит символ сравнения, или значение разделения и три указателя на другие последующие узлы, или узлы-потомки в дереве. Эти указатели осуществляют ссылку на узлыпотомки, чьи значения разделения меньше, равны, или больше значений разделения узла. Следовательно,поиск по TST по конкретному ключу включает прохождение по дереву от корневого узла до конечного концевого узла, при последовательном сравнении каждого элемента, или позиции символа ключа с значениями разделения узлов на пути. Дополнительно, концевой узел также может содержать указатель на ключевую запись, которая может, в свою очередь, содержать, по меньшей мере, один указатель на конечную запись данных, содержащую данные записи, соответствующие ключу, (например, адрес IP). В другом варианте, ключевая запись может полностью содержать данные записи. Данные записи могут храниться в двоичном формате, формате текста ASCII и т.д. В одном варианте осуществления база данных 700 может быть организована в виде TST, содержащем несколько узлов 701 поиска фиксированной длины, множества записей 702 данных ключа перемен-9 005646 ной длины и множества записей 703 конечных данных переменной длины. Узлы 701 поиска, как описано выше, могут содержать различные виды информации, включая, например, символ (или значение) и позицию сравнения, указатели узла ветви и указатель ключа. Размер указателей узла, в основном, может определяться количеством узлов, в то время, как размер указателей ключа, в основном, может определяться размером набора данных ключа переменной длины. Записи 702 данных ключа могут содержать информацию о ключе и информацию о конечных данных, включая, например, указатели на записи конечных данных или внедренные данные записи, в то же время записи 703 конечных данных могут содержать данные записи. В варианте осуществления каждый узел поиска фиксированной длины может иметь 24 байта в длину. Узел поиска 710, например, может содержать восьмибитовый символ 711 (или байтовое значение) сравнения, 12-битную позицию 712 символа (или байта), и 12-битный тип/состояние узла (для ясности не изображен); эти данные могут быть закодированы в первых четырех байтах узла. Символ 711 сравнения может быть закодирован в первом байте узла, как указано на фиг. 7, или, в другом варианте, позиция 712 символа может быть закодирована в первых 12 битах узла для оптимизации доступа к позиции 712 символа с использованием простой операции смещения. Следующие 12 байтов каждого узла поиска могут содержать три 32-битных указателя, то есть, указатель 713, указатель 714 и указатель 715, представляющие указатели узлов ветвей "меньше чем", "равно" и "больше чем", соответственно. Эти указатели вместо смещения байтов или адреса памяти, могут содержать счетчик, или индекс узла. Для узлов поиска фиксированной длины смещение байтов может быть вычислено по счетчику или значению индекса и фиксированной длине, например, как счетчикдлина. Конечные 4 байта могут содержать 40-битный указатель 716 ключа, которым может быть нулевое значение, указывающее, что соответствующая запись данных ключа не существует (изображено) или указатель на существующую соответствующую запись данных ключа (не изображен), а также другие данные, включая, например, 12-битную длину ключа и 12 битное поле типа/состояния указателя. Указатель 716 ключа может содержать смещение байтов для соответствующей записи данных ключа, в то же время длина ключа может использоваться для оптимизации поиска и вставки при исключении однонаправленного перехода по ветви внутри TST. Поле типа/состояния указателя может содержать информацию, используемую при проверке достоверности и распределении данных, используемых для управления памятью. В варианте осуществления запись 750 данных ключа может содержать, например, ключ 753 переменной длины и, по меньшей мере, один указатель конечных данных. Как указано на фиг. 7, запись 750 данных ключа содержит два указателя конечных данных: указатель 757 конечных данных и указатель 758 конечных данных. В начале записи 750 данных ключа могут быть присоединены 12 битная длина 751 ключа и 12-битный счетчик/состояние 752 конечного указателя, и она может содержать заполнение(для ясности не изображено) для выравнивания указателя 757 конечных данных 757 и указателя 758 конечных данных 758 по границе 8-байтов в памяти 104. Каждый указатель 757 конечных данных и указатель 758 конечных данных может содержать разные данные, например, такие как длину, состояние, тип конечных данных или данные, используемые для поисков по двоичным записям. Указатель 757 конечных данных и указатель 758 конечных данных может быть отсортирован по типу конечных данных для более быстрого поиска записей конкретного ресурса (например, запись 760 конечных данных и запись 770 конечных данных). В другом варианте осуществления запись 740 данных ключа может содержать внедренные конечные данные 746 вместо или в дополнение к указателям на записи конечных данных. Например, запись 740 данных ключа может содержать длину 741 ключа, счетчик 742 конечных указателей, ключ 743 переменной длины, количество внедренных элементов 744 записи, с последующей длиной 745 элемента записи (например, в байтах) и данные 746 внедренной записи 746 (например, строка, последовательность байтов, и т.д.) для каждого из нескольких элементов 744 внедренной записи. В варианте осуществления запись 760 конечных данных, например, может содержать 12-битную длину 761, 4-битное состояние и строку 762 переменной длины (например, адрес IP). В другом варианте,строкой 762 переменной длины может быть последовательность байтов. Запись 760 конечных данных может содержать заполнение для выравнивания каждой записи конечных данных по границе 8-байтов в памяти 104. В другом варианте, запись 760 конечных данных 760 может содержать заполнение до границы 4-байтов, или, запись 760 конечных данных может не содержать заполнения. В основном алгоритмы управления памятью могут определять, заполняются ли записи 760 конечных данных до границ 8-байтов,4-байтов или 0-байтов. Аналогично, запись 770 конечных данных может содержать 12-битную длину 771, 4-битное состояние и строку 772 переменной длины (например, адрес IP). В основном, индексы поиска, такие как TST, и записи данных могут быть структурированы так,чтобы 8-байтовые указатели были размещены на границах 8-байтов в памяти. Например, указатель 726 ключа может содержать 8-байтовый (или меньшего размера) указатель на запись 740 данных ключа, и может храниться в адресе памяти, делимом на восемь (то есть границе 8-байтов, или 8N). Аналогично,индексы поиска, такие как TST, и записи данных могут быть структурированы так, чтобы 4-байтовые указатели были размещены на границах 4-байтов в памяти. Например, указатель 724 узла ветви может содержать 4-байтовый (или меньшего размера) указатель на узел 730, и может храниться в адресе памяти, делимом на четыре (то есть, границе 4-байтов, или 4N). Следовательно, изменения в базе данных 700-10 005646 могут заключаться в обновлении указателя в выровненном адресе в памяти, с использованием одиночной непрерываемой операции, включающей, например, запись нового указателя в индекс поиска, такой как узел TST, или запись нового указателя в запись данных. На фиг. 8 представлена подробная структурная схема, иллюстрирующая другую архитектуру структуры данных, согласно варианту осуществления настоящего изобретения. Как описано выше, база 800 данных также может быть организована в единое представление данных с возможностью осуществления поиска. Обновления наборов данных могут постоянно включаться в базу 800 данных, и удаления или изменения для релевантных записей базы данных могут выполняться физически для освобождения пространства в памяти 104, например, для последующих добавлений или изменений. Единое представление с возможностью осуществления поиска очень хорошо масштабируется для больших размеров наборов данных и высоких скоростей обновления и поиска и устраняет потребность в периодическом повторном создании, распространении и перезагрузке файлов кадра по множеству компьютеров механизма поиска. Для доступа к данным записи возможны другие структуры индекса поиска. В варианте осуществления база 800 данных может использовать альтернативный упорядоченный индекс поиска, организованный как упорядоченное дерево ключей доступа (то есть, "дерево OAK"). База 800 данных может содержать, например, множество узлов 801 поиска переменной длины, множество ключевых записей 802 переменной длины и множество записей 803 конечных данных переменной длины. Как описано выше, узлы 801 поиска могут содержать различные виды информации, например, такие как поисковые ключи,указатели на другие узлы поиска, указатели на ключевые записи и т.д. В варианте осуществления множество узлов 801 поиска могут содержать вертикальные и горизонтальные узлы, содержащие фрагменты поисковых ключей (например, строки), а также указатели на другие узлы поиска или ключевые записи. Вертикальные узлы, например, могут содержать, по меньшей мере, один поисковый ключ, или символ,указатели на горизонтальные узлы в множестве узлов 801 поиска, указатели на ключевые записи в множестве ключевых записей 802 и т.д. Горизонтальные узлы, например, могут содержать, по меньшей мере,два поисковых ключа, или символа, указатели на вертикальные узлы в множестве узлов 801 поиска, указатели на горизонтальные узлы в множестве узлов 801 поиска, указатели на ключевые записи в множестве ключевых записей 802 и т.д. В основном, вертикальные узлы могут содержать последовательность ключей (например, символов), представляющую фрагмент поискового ключа (например, строку), в то же время горизонтальные узлы могут содержать разные ключи (например, символы) которые могут находиться в определенной позиции в фрагменте поискового ключа (например, строки). В варианте осуществления множество узлов 801 поиска может содержать вертикальный узел 810,вертикальный узел 820 и горизонтальный узел 830. Вертикальный узел 810 может содержать, например,2-битный тип 811 узла (например, "10"), 38-битный адрес 812, 8-битную длину 813 (например, "8"), 8 битный первый символ 814 (например, "1") и 8-битный второй символ 815 (например, символ нуля"null"). В этом примере адрес 812 может указывать на следующий узел в дереве поиска, то есть, вертикальный узел 820. В варианте осуществления 38-битный адрес 812 может содержать 1-битный конечный/узловой индикатор и 37-битный относительный адрес для ссылки на одно из 8-байтовых слов в адресном пространстве в 1 Tbyte (1012 байт) памяти 104. Соответственно, вертикальный узел 810 может иметь восемь байтов (64 бита) в длину, и, преимущественно, может быть размещен на границе 8 байтового слова в памяти 104. В основном, каждый вертикальный узел в множестве узлов 801 поиска может быть размещен на границе 8-байтового слова в памяти 104. Вертикальный узел может содержать многосимвольный фрагмент поискового ключа (например,строку). В основном, поисковые ключи без ассоциированных записей данных ключа могут быть свернуты в одиночный вертикальный узел для эффективного уменьшения количества вертикальных узлов, требуемых в множестве узлов 801 поиска. В варианте осуществления вертикальный узел 810 может содержать 8 битов для каждого дополнительного символа, более двух символов в фрагменте поискового ключа, таких как, например, 8-битные символы 816-1, 816-2816-N (изображены в фантомном контуре). Преимущественно, вертикальный узел 810 может быть заполнен до 64-битной границы в памяти 104, в соответствии с количеством дополнительных символов, размещенных в фрагменте строки. Например,если в вертикальный узел 810 должны быть включены девять символов, то символы один и два могут быть назначены первому символу 814 и второму символу 815, соответственно, а 56 битов информации дополнительных символов, соответствующей символам с третьего по девятый, могут быть присоединены к вертикальному узлу 810. Для выравнивания информации дополнительных символов относительно границы 8-байтового слова могут быть включены дополнительные восемь битов заполнения. Аналогично, вертикальный узел 820 может содержать, например, 2-битный тип 821 узла (например,"10"), 38-битный адрес 822, 8-битную длину 823 (например, "8"), 8-битный первый символ 824 (например, "а") и 8-битный второй символ 825 (например, "нуль"). В этом примере адрес 822 может указывать на следующий узел в дереве поиска, то есть, горизонтальный узел 830. Соответственно, вертикальный узел 820 может иметь длину восемь байтов, и, преимущественно, может быть размещен на границе 8 байтового слова в памяти 104. Безусловно, в вертикальном узле 820, если требуется, также может содержаться дополнительная информация, как описано выше в отношении вертикального узла 810.-11 005646 Горизонтальный узел 830 может содержать, например, 2-битный тип 831 узла (например, "01"), 38 битный первый адрес 832, 8-битный счетчик 833 адреса (например, 2), 8-битный первый символ 834 (например, ), 8-битный последний символ 835 (например, "w"), растр (битовую карту) 836 переменной длины и 38-битный второй адрес 837. В этом примере первый символ 834 может содержать одиночный символ, , представляющий фрагмент "1 а" поискового ключа, определенный вертикальными узлами 810 и 820, в то же время последний символ 831 может содержать одиночный символ "w", представляющий фрагмент "law" поискового ключа, определенный вертикальными узлами 810 и 820 и последним символом 835 горизонтального узла 830. Первый адрес 832 может указывать на запись 840 данных ключа, соответствующую фрагменту "1 а" поискового ключа, в то же время второй адрес 837 может указывать на запись 850 данных ключа, соответствующую фрагменту "law" поискового ключа. Растр (битовая карта) 836 может преимущественно указывать, на какие ключи (например, символы) осуществляет ссылку горизонтальный узел 830. Единица "1" в позиции бита в растре 836 указывает, что горизонтальный узел 830 осуществляет ссылку на ключ, или символ, в то же время "0" в позиции бита в растре 836 может указывать, что горизонтальный узел 830 не имеет ссылки на ключ, или символ. В основном, длина растра 836 может зависеть от количества последовательных ключей, или символов, между первым символом 834 и последним символом 835, включая эти граничные символы. Например, если первым символом 834 является "а", а последним символом 835 является "z", то растр 836 может иметь длину 26 битов, где каждый бит соответствует одному из символов от "а" до "z", включая "а" и "z". В этом примере, в конце горизонтального узла 830 должны быть присоединены дополнительные 38-битные адреса, соответствующие каждому из символов, представленных в растре 836. Каждый из этих 38 битных адресов, а также растр 836, могут быть заполнены для выравнивания каждого числа до границы 8-байтового слова в памяти 104. В варианте осуществления, в качестве пространства поискового ключа может быть использован набор 8-битовых символов ASCII, так что растр 836 может иметь длину 256 битов (то есть 28 битов или 32 байта). В примере, иллюстрируемом фиг. 8, из-за специального ссылочного символа и счетчика 833 адреса "2", растр 836 может иметь длину два бита и может содержать "1" в каждой битовой позиции, соответствующей последнему символу 835. В варианте осуществления, как описано в отношении записи 750 данных ключа (фиг. 7), запись 850 данных ключа может содержать, например, ключ 853 переменной длины и, по меньшей мере, один указатель конечных данных. Как иллюстрируется на фиг. 8, запись 850 данных ключа содержит два указателя конечных данных, указатель 857 конечных данных и указатель 858 конечных данных. В начале записи 850 данных ключа могут быть присоединены 12-битная длина 851 ключа и 12-битный счетчик/состояние 852 конечных указателей, и она может содержать заполнение (для ясности не изображено) для выравнивания указателя 857 конечных данных и указателя 858 конечных данных на границе 8-байтов в памяти 104. Каждый указатель 857 конечных данных и указатель 858 конечных данных может содержать 10 битный тип конечных данных и другие данные, например, такие как длина, состояние или данные, используемые при поисках двоичных записей. Указатель 857 конечных данных и указатель 858 конечных данных могут быть отсортированы по типу конечных данных для более быстрого поиска записей конкретного ресурса (например, запись 860 конечных данных и запись 870 конечных данных). В другом варианте осуществления, как описано выше в отношении записи 740 данных ключа (фиг. 7), запись 840 данных ключа может содержать внедренные конечные данные 846 вместо указателя на запись конечных данных. Например, запись 840 данных ключа может содержать длину 841 ключа, счетчик 842 конечных указателей, ключ 843 переменной длины, количество внедренных элементов 844 записи с последующей длиной 845 элемента записи (например, в байтах) и внедренные данные 846 записи(например, строка, последовательность байтов и т.д.) для каждого из внедренных элементов 844 записи. В другом варианте осуществления, как описано в отношении записи 760 конечных данных (фиг. 7),запись 860 конечных данных, например, может содержать 12-битную длину 861, 4-битное состояние и строку 862 переменной длины (например, адрес IP). В другом варианте, строка 862 переменной длины может представлять собой последовательность байтов. Запись 860 конечных данных может содержать заполнение (для ясности не изображено) для выравнивания каждой записи конечных данных на границе 8-байтов в памяти 104. В другом варианте, запись 860 конечных данных может содержать заполнение(для ясности не изображено) до границы 4-байтов, или запись 860 конечных данных может не содержать заполнения. В основном алгоритмы управления памятью могут определять, заполняются ли записи 860 конечных данных до границы 8-байтов, 4-байтов или 0-байтов. Аналогично, запись 870 конечных данных может содержать 12-битную длину 871, 4-битное состояние и строку 872 переменной длины (например, адрес IP). В основном, индексы поиска, такие как деревья OAK, и записи данных могут быть структурированы так, чтобы 8-байтовые указатели были размещены в памяти на границах 8-байтов. Например, вертикальный узел 810 может содержать 8-байтовый (или меньшего размера) указатель на вертикальный узел 820 и может храниться в адресе памяти, делимом на восемь (то есть границе 8-байтов, или 8N). Аналогично, индексы поиска, такие как деревья OAK, и записи данных могут быть структурированы так, чтобы 4-байтовые указатели были размещены на границах 4-байтов в памяти. Следовательно, изменения в базе данных 800 могут включаться посредством обновления указателя в выровненном адресе в памяти, с-12 005646 использованием одиночной непрерываемой операции, включающей, например, запись нового указателя в индекс поиска, такой как узел деревьев OAK, или запись нового указателя в запись данных. Различные варианты осуществления, описанные выше в отношении фиг. 8, имеют многие преимущества. Например, структура данных дерева OAK является очень эффективной в отношении используемого пространства и 8-битной очистки. Могут использоваться поиски регулярного выражения для поиска по вертикальным узлам, содержащим многосимвольные фрагменты строки, так как 8-битный первый символ (например, первый символ 814), 8-битный второй символ (например, второй символ 815) и любые дополнительные 8-битные символы (например, дополнительные символы 816-1816-N) могут быть размещены непрерывно в пределах вертикального узла (например, вертикального узла 810). Неудачи при поиске могут быть обнаружены быстро, и для поиска строки N-символьной длины требуется пройти не более N узлов. На фиг. 9 представлена блок-схема верхнего уровня, иллюстрирующая способ поиска и параллельного обновления базы данных без использования блокировок базы данных или средств управления доступом, согласно вариантам осуществления настоящего изобретения. Могут быть созданы (900) поток обновления и несколько потоков поиска. В варианте осуществления система 100 может порождать единый поток обновления для включения в локальную базу данных обновлений, полученных, например, из OLTP сервера 140-1 через ГС 124. В других вариантах осуществления система 100 может получать обновления из OLTP серверов 140-1140-S через ГС 124 и из множества сетевых компьютеров 120-1120-N через ГС 124 или ЛС 122. Система 100 также может порождать поток поиска в отношении каждого запроса сеанса, полученного из множества сетевых компьютеров 120-1120-N. Например, управляющий поток может опрашивать один или большее количество портов управления, соответствующих одному или большему количеству сетевых интерфейсов 114-1114-О, на запросы сеанса, переданные из множества сетевых компьютеров 120-1120-N. При получении запроса сеанса из конкретного сетевого компьютера 120-1120-N, управляющий поток может породить поток поиска и сопоставить поток поиска этому конкретному сетевому компьютеру (например,РЕ). В альтернативном варианте осуществления система 100 может порождать несколько потоков поиска без опроса на запросы сеанса из множества сетевых компьютеров 120-1120-N. В этом варианте осуществления потоки поиска могут не соответствовать конкретным сетевым компьютерам и могут быть распределены равномерно по множеству процессоров 102-1102-Р. В другом варианте потоки поиска могут выполняться на наборе из множества процессоров 102-1102-Р. Количество потоков поиска не обязательно должно соответствовать количеству сетевых компьютеров (например, N). Через сеть связи может быть получено (910) множество запросов на поиск. В варианте осуществления множество сетевых компьютеров 120-1120-N может передать множество запросов на поиск в систему 100 через ЛС 122, или, в другом варианте, ГС 124. Множество запросов на поиск может содержать,например, признак поиска или ключ, а также информацию о состоянии, которая может соответствовать каждому запросу (например, адрес источника запроса, тип протокола, и т.д.). Информация о состоянии может прямо обеспечиваться системой 100, или, в другом варианте, может быть предусмотрен дескриптор информации о состоянии. В предпочтительном варианте осуществления каждый из множества сетевых компьютеров 120-1120-N может мультиплексировать предварительно определенное количество запросов на поиск в единый пакет сети для передачи к системе 100 (например, Суперпакет 220 Запроса,как описано согласно фиг. 2). Каждый запрос на поиск может быть назначен (920) для обработки одному из потоков поиска. В варианте осуществления каждый поток поиска может соответствовать одному из множества сетевых компьютеров 120-1120-N, и все запросы на поиск, полученные от этого конкретного сетевого компьютера, могут быть назначены (920) потоку поиска. Другими словами, один поток поиска может обрабатывать все запросы на поиск, поступающие из одного сетевого компьютера (например, одного РЕ). В варианте осуществления каждый поток поиска может извлекать индивидуальные запросы на поиск из одиночного мультиплексированного пакета сети (например, Суперпакет 220 Запроса 220, как описано согласно фиг. 2), или, в другом варианте, извлечение может выполняться другим процессом или потоком. В другом варианте осуществления запросы на поиск, полученные от каждого из множества сетевых компьютеров 120-1120-N, могут быть назначены (920) разным потокам поиска. В этом варианте осуществления многопоточное назначение может основываться на оптимальной функции распределения,которая может содержать разные параметры системы, включая, например, загрузку процессора. Безусловно, назначение запросов на поиск потокам поиска может с течением времени изменяться на основе различных параметров системы, включая доступность процессора, эффективность компонентов системы и т.д. Для передачи запросов на поиск назначенным потокам поиска в системе 100 могут использоваться различные механизмы, например, такие как совместно используемая память, межпроцессные сообщения,маркеры, семафоры и т.д. Каждый поток поиска может осуществлять поиск (930) по базе данных на основе назначенных запросов на поиск. Поиск по базе данных может зависеть от глубинной структуры базы данных.-13 005646 Согласно варианту осуществления базы данных, иллюстрируемому фиг. 4, по базе данных 400 может быть осуществлен поиск (930) для поискового ключа. Затем может быть определена запись данных(например, запись 420 базы данных), соответствующая поисковому ключу. Согласно варианту осуществления базы данных, показанному на фиг. 5, сначала может быть осуществлен поиск (930) по файлу 520 предыстории для поискового ключа, и, если не обнаружено соответствие, то может быть осуществлен поиск (930) по файлу 510 кадр. Затем может быть определена запись данных, соответствующая поисковому ключу. Согласно варианту осуществления базы данных, показанному на фиг. 6, сначала может быть осуществлен поиск (930) по данным 610 имен доменов для поискового ключа, и затем могут быть определены данные ресурса в данных 630 серверов доменных имен, соответствующих поисковому ключу. Например, для поискового ключа "la.com" может быть определено соответствие с записью 620 имени домена в данных 610 имен доменов. Может быть извлечена соответствующая информация, включая, например, указатель 626 сервера доменных имен. Затем, соответствующая запись 640 сервера доменных имен может быть индексирована с использованием указателя 626 сервера доменных имен, и может быть извлечен сетевой адрес 647 сервера доменных имен. Согласно варианту осуществления базы данных, показанному на фиг. 7, может быть осуществлен поиск (930) по TST для поискового ключа, из которого могут быть определены данные ресурса. Например, для поискового ключа "law.com" может быть осуществлен поиск (930) по узлам 701 поиска, и может быть обнаружено соответствие с узлом 730. Может быть извлечен указатель 736 ключа, из которого может быть определена запись 750 данных ключа. Затем может быть идентифицировано определенное количество указателей 752 конечных данных, и может быть извлечен каждый указатель конечных данных. Например, указатель 757 конечных данных может осуществлять ссылку на запись 760 конечных данных,а указатель 758 конечных данных может осуществлять ссылку на запись 770 конечных данных. Затем из каждой записи конечных данных могут быть извлечены данные ресурса переменной длины, например,сетевой адрес 762 сервера доменных имен и сетевой адрес 772 сервера доменных имен, с использованием длины 761 и 771, соответственно. Согласно варианту осуществления базы данных, показанному на фиг. 8, может быть осуществлен поиск (930) по дереву OAK для поискового ключа, из которого могут быть определены данные ресурса. Например, для поискового ключа "law.com" может быть осуществлен поиск (930) по узлам 801 поиска и определено соответствие с узлом 830. Может быть извлечен второй адрес 837, из которого может быть определена запись 850 данных ключа. Затем может быть идентифицировано определенное количество указателей 852 конечных данных, и может быть извлечен каждый указатель конечных данных. Например, указатель 857 конечных данных может осуществлять ссылку на запись 860 конечных данных, а указатель 858 конечных данных может осуществлять ссылку на запись 870 конечных данных. Затем из каждой записи конечных данных могут быть извлечены данные ресурса переменной длины, например, сетевой адрес 862 сервера доменных имен и сетевой адрес 872 сервера доменных имен, с использованием длины, 861 и 871, соответственно. Каждый поток поиска может создавать (940) несколько ответов по поиску, соответствующих назначенным запросам на поиск. Если для конкретного поискового ключа соответствие не обнаружено, то ответ может содержать соответствующую индикацию, например, такую как символ нуля. Для разрешения имен доменов, например, поисковым ключом может быть "law.com", a соответствующими данными ресурса могут быть "180.1.1.1". Поисковому ключу может соответствовать более одного сетевого адреса сервера доменных имен, в этом случае может быть определено более одного сетевого адреса сервера доменных имен. Ответы могут быть переданы (950) через сеть связи. В варианте осуществления каждый поток поиска может мультиплексировать соответствующие ответы в единый пакет сети (например, Суперпакет 240 Ответа), соответствующий единому пакету сети, содержащему исходные запросы (например, Суперпакет 220 Запроса). В другом варианте, другой процесс или поток может мультиплексировать соответствующие ответы в единый пакет сети. Затем пакет сети ответа может быть передан (950) соответствующему сетевому компьютеру из множества сетевых компьютеров 120-1120-N через ЛС 122, или в другом варианте, через ГС 124. В одном варианте осуществления пакеты ответа могут быть переданы тем сетевым компьютерам, из которых исходили пакеты запроса, в то же время в другом варианте осуществления пакеты ответа могут быть переданы другому сетевому компьютеру. Поток обновления может получать (960) через сеть связи новую информацию. В варианте осуществления новая информация может быть передана в систему 100, например, из OLTP сервера 140-1 через ГС 124. В других вариантах осуществления система 100 может получать обновления из OLTP серверов 140-1140-S через ГС 124, и от множества сетевых компьютеров 120-1120-N через ГС 124 или ЛС 122. В варианте осуществления разрешения DNS, например, новая информация может содержать новые данные имен доменов, новые данные сервера доменных имен, новый сервер доменных имен для существующих имен доменов и т.д. В другом варианте, новая информация может указывать, что имя домена,сервер доменных имен, сетевой адрес сервера доменных имени т.д. могут быть удалены из базы данных.-14 005646 В основном, любая информация, содержащаяся в базе данных, может быть добавлена, изменена или удалена, как целесообразно. Поток обновления может создавать (970) новый элемент в базе данных, содержащей новую информацию. В основном, изменения информации, содержащейся в существующем элементе базы данных включаются посредством создания нового элемента на основе существующего элемента и затем изменения нового элемента для включения новой информации. В течение указанного процесса новый элемент не может быть видим для потоков поиска или процессов, выполняющихся в текущий момент системой 100, пока новый элемент не будет зафиксирован в базе данных. В основном, добавления к базе данных могут быть выполнены подобным способом, без обязательного использования информации, содержащейся в существующем элементе. В одном варианте осуществления удаление существующего элемента из базы данных может быть выполнено посредством добавления в базу данных нового элемента, явного"удаления". В другом варианте осуществления удаление существующего элемента из базы данных может быть выполнено посредством перезаписи указателя на существующий элемент с соответствующим индикатором (например, нулевой указатель и т.д.). В этом варианте осуществления, поток обновления не создает новый элемент в базе данных, содержащей новую информацию. В варианте осуществления разрешения DNS, например, новая информация может содержать новое имя домена, которое будет добавлено в базу данных. В этом возможном варианте, для простоты, новое имя домена может осуществлять ссылку на существующий сервер доменных имен. Согласно фиг.6, пространство памяти для записи 615 нового имени домена может быть распределено из пула памяти, соответствующего записям 611 имен доменов, или, в другом варианте, из общего пула памяти, соответствующего данным 610 имен доменов. Новое имя домена может быть нормировано и скопировано в запись 615 нового имени домена, и указатель на существующий сервер доменных имен (например, запись 655 сервера доменных имен) может быть определен и скопирован в запись 615 нового имени домена. Другая информация может быть вычислена и добавлена в запись нового имени домена, например, такая как количество серверов доменных имен, указатель цепочки и т.д. В более сложных примерах новая информация может содержать новый поисковый ключ с соответствующими данными ресурса. Согласно фиг. 7, сначала могут быть созданы новый узел 705 поиска, а также новая запись 780 данных ключа. В этом возможном варианте новый узел 750 поиска может содержать символ сравнения("m"), в первой позиции, который больше символа сравнения ("l"), в первой позиции существующего узла 710 поиска. Следовательно, узел 705 поиска может быть вставлен в TST на том же "уровне" (то есть 1-ая позиция символа), что и узел 710 поиска. До фиксации узла 705 поиска в базе данных, 4-байтовый указатель 715 "больше чем" узла 710 поиска может содержать нулевой указатель. Узел 705 поиска может также содержать 4-байтовый указатель 706 ключа, который может содержать 40-битный указатель на новую запись 780 данных ключа. Запись 780 данных ключа может содержать длину 781 ключа (например, "5") и тип 782 (например, указывающий внедренные данные ресурса), ключ 783 переменной длины(например, "m.com"), количество внедренных ресурсов 784 (например, "1"), длину 785 ресурса (например, "9") и строку 786 ресурса переменной длины или последовательность байтов (например,"180.1.1.1"). В варианте осуществления пространство памяти для узла 705 поиска может быть распределено из пула памяти, соответствующего узлам 701 TST, в то же время пространство памяти для записи 770 данных ключа может быть распределено из пула памяти, соответствующего множеству записей 702 данных ключа. Согласно фиг. 8 сначала могут быть созданы новый узел 890 поиска, а также новая запись 880 данных ключа. В этом возможном варианте, новый узел 890 поиска может быть горизонтальным узлом, содержащим, например, 2-битный тип 891 узла (например, "01"), 38-битный первый адрес 892, 8-битный счетчик 893 адреса (например, 2), 8-битный первый символ 894 (например, "1"), 8-битный последний символ 895 (например, "m"), растр 896 переменной длины и 38-битный второй адрес 897. Первый адрес 892 может указывать на вертикальный узел 820, следующий вертикальный узел на пути строки поиска"I", в то же время второй адрес 897 может указывать на запись 880 данных ключа, соответствующую фрагменту "m" поискового ключа. Запись 880 данных ключа может содержать длину 881 ключа (например, "5") и тип 882 (например, указывающий внедренные данные ресурса), ключ 883 переменной длины(например, "m.com"), количество внедренных ресурсов 884 (например, "1"), длину ресурса 885 (например, "9"), и строку 886 ресурса переменной длины или последовательность байтов (например,"180.1.1.1"). В варианте осуществления пространство памяти для узла 890 поиска может быть распределено из пула памяти, соответствующего нескольким узлам 801 поиска, в то же время пространство памяти для записи 880 данных ключа может быть распределено из пула памяти, соответствующего нескольким записям 802 данных ключа. Поток обновления может записывать (980) указатель в базу данных, с использованием одиночной непрерываемой операции. В основном, новый элемент может быть фиксирован в базе данных, (то есть,становится видимым для процессов, или потоков поиска) мгновенно, посредством записи указателя на новый элемент в соответствующее местоположение в базе данных. Как описано выше, соответствующее местоположение может быть выровнено в памяти, так, чтобы одиночная операция включала одиночную инструкцию сохранения соответствующей длины. В варианте осуществления существующий элемент-15 005646 может быть удален из базы данных (то есть становится невидимым для процессов, или потоков поиска) мгновенно, посредством перезаписи указателя на существующий элемент с соответствующим индикатором (например, нулевой указатель и т.д.). Опять же, соответствующее местоположение может быть выровнено в памяти, так, чтобы одиночная операция включала одиночную инструкцию сохранения соответствующей длины. Согласно фиг.6 8-байтовый указатель, соответствующий записи 620 имен доменов может быть записан в хэш-таблицу 612 (например, элемент 613). Существенно, что входы хэш-таблицы выровнены в памяти 104 по границам 8-байтов для обеспечения использования одиночной 8-байтовой команды сохранения для обновления этого значения. Согласно фиг.7, 4-байтовый указатель, соответствующий новому узлу 705 поиска, может быть записан в 4-байтовый указатель 715 узла "больше чем" внутри узла 710 поиска. Существенно, что указатель 715 узла выровнен в памяти 104 по границе 4-байтов, для обеспечения использования одиночной 4-байтовой команды сохранения для обновления этого значения. Согласно фиг. 8, множество узлов 801 поиска может также содержать адрес 899 вершины дерева, который может быть выровнен в памяти 104 по границе 8-байтового слова и осуществляет ссылку на первый узел из множества узлов 801 поиска (то есть, например, вертикальный узел 810). 8-байтовый указатель, соответствующий новому узлу 890 поиска, может быть записан в адрес 899 вершины дерева с использованием одиночной команды сохранения. В каждом из указанных вариантов осуществления, непосредственно до команды сохранения, новые данные не видимы для потоков поиска, в то же время сразу после команды сохранения новые данные становятся видимыми для потоков поиска. Следовательно, с использованием одиночной непрерываемой операции, новые данные могут быть фиксированы в базе данных без использования блокировок базы данных или средств управления доступом. В варианте осуществления, после записи (980) указателя в базу данных, поток обновления может физически удалить (990) существующий элемент. Преимущественно, для существующих элементов базы данных, которые изменяются или удаляются, физическое удаление этих элементов из памяти 104 может быть задержано для сохранения согласованности в осуществляемых поисках. Например, после изменения существующего элемента и фиксации в базе данных соответствующего нового элемента, физическое удаление существующего элемента из памяти 104 может быть задержано, чтобы существующие потоки поиска, которые получают результат, приобретенный непосредственно перед фиксацией в базе данных нового элемента, мог продолжать использовать предыдущее состояние данных. Аналогично, после удаления существующего элемента из базы данных, физическое удаление существующего элемента из памяти 104 может быть задержано, чтобы существующие потоки поиска, которые получают результат,приобретенный непосредственно перед удалением из базы данных существующего элемента, могли продолжать использовать предыдущее состояние данных. Поток обновления может физически удалить (990) существующий элемент после завершения всех потоков поиска, которые начались до изменения или удаления существующего элемента. В результате взаимодействия способов, соответствующих вариантам осуществления настоящего изобретения, и различных характеристик архитектуры системы 100 могут возникнуть потенциальные осложнения. Например, процессор, на котором выполняется поток обновления (например, процессор 102-1, 102-2 и т.д.) может содержать аппаратные средства для поддержания исполнения команд с изменением последовательности. В другом возможном варианте система 100 может содержать оптимизирующий компилятор, который может создавать последовательность команд, соответствующих вариантам осуществления настоящего изобретения, реорганизованных оптимальным образом для использования параллельности внутренней архитектуры процессора (например, процессора 102-1, 102-2 и т.д.). Для специалистов в данной области техники очевидны многие другие осложнения. Риск сбоя данных, являющийся результатом исполнения команд с изменением последовательности, может быть исключен,например, посредством создания зависимостей между созданием (970) нового элемента и записью (980) указателя в базу данных. В одном варианте осуществления такие зависимости могут быть установлены посредством вставки в последовательность команд, выполняемых процессором 102-1, дополнительных арифметических операций, например, таких как команда исключающее ИЛИ (XOR), для принудительного выполнения команд, соответствующих созданию (970) нового элемента, для выдачи, или завершения, перед выполнением записи указателя в базу данных. Например, может быть осуществлена операция XOR содержимого ячейки памяти 104, соответствующей новому элементу, с содержимым ячейки памяти 104, соответствующей указателю на новый элемент. Адрес нового элемента затем может быть записан (980) в память 104 для фиксации нового элемента в базе данных. Для специалистов в данной области техники могут быть очевидны многочисленные способы преодоления указанных осложнений. Выше подробно описаны и проиллюстрированы некоторые из вариантов осуществления настоящего изобретения. Однако, очевидно, что без отклонения от сущности объема настоящего изобретения могут быть осуществлены изменения и модификации изобретения, охватываемые приведенным выше описанием и приложенной формулой изобретения.-16 005646 ФОРМУЛА ИЗОБРЕТЕНИЯ 1. Система многопоточной сетевой базы данных, содержащая по меньшей мере, один процессор, связанный с сетью, и память, связанную с процессором, причем память содержит базу данных и команды, предназначенные для выполнения процессором, для создания потока обновления и множества потоков поиска,назначения каждого из множества запросов на поиск, полученных через сеть, одному из множества потоков поиска,для каждого потока поиска: осуществления поиска по базе данных в соответствии с назначенными запросами на поиск,создания множества ответов по поиску, соответствующих назначенным запросам на поиск, и передачи множества ответов по поиску через сеть, и для потока обновления: создания нового элемента в соответствии с новой информацией, полученной через сеть, и без ограничения доступа к базе данных для множества потоков поиска, записи указателя на новый элемент в базу данных с использованием одиночной непрерываемой операции. 2. Система по п.1, отличающаяся тем, что одиночная непрерываемая операция представляет собой команду сохранения. 3. Система по п.1, отличающаяся тем, что дополнительно содержит для потока обновления: физическое удаление существующего элемента из памяти после записи указателя в базу данных. 4. Система по п.2, отличающаяся тем, что команда сохранения записывает 4 байта в адрес памяти,размещенный на границе 4 байтов. 5. Система по п.2, отличающаяся тем, что команда сохранения записывает восемь байтов в адрес памяти, размещенный на границе 8 байтов. 6. Система по п.2, отличающаяся тем, что процессор имеет длину машинного слова, по меньшей мере, в n-байтов, память имеет разрядность, по меньшей мер, в n-байтов, и команда сохранения записывает n-байтов в адрес памяти, размещенный на n-байтовой границе. 7. Система по п.1, отличающаяся тем, что множество запросов на поиск принимается в одиночном пакете сети. 8. Система по п.1, отличающаяся тем, что множество ответов по поиску передается в одиночном пакете сети. 9. Система по п.1, отличающаяся тем, что упомянутое ограничение доступа включает в себя блокировку базы данных. 10. Система по п.1, отличающаяся тем, что упомянутое ограничение доступа включает в себя взаимоблокировку. 11. Система по п.10, отличающаяся тем, что взаимоблокировка включает в себя использование, по меньшей мере, одного семафора. 12. Система по п.11, отличающаяся тем, что упомянутый семафор является семафором мьютекса. 13. Система по п.1, отличающаяся тем, что дополнительно содержит множество процессоров и симметричную многопроцессорную операционную систему. 14. Система по п.13, отличающаяся тем, что множество потоков поиска выполняет, по меньшей мере, 100000 поисков в секунду. 15. Система по п.14, отличающаяся тем, что поток обновления выполняет, по меньшей мере, 10000 обновлений в секунду. 16. Система по п.15, отличающаяся тем, что поток обновления выполняет от 50000 до 130000 обновлений в секунду. 17. Система по п.1, отличающаяся тем, что указатель на новый элемент записан в индекс поиска. 18. Система по п.17, отличающаяся тем, что индекс поиска представляет собой TST (тернарное дерево поиска). 19. Система по п.17, отличающаяся тем, что индекс поиска представляет собой хэш-таблицу. 20. Система по п.1, отличающаяся тем, что указатель на новый элемент записан в запись данных в базе данных. 21. Способ поиска и параллельного обновления базы данных, заключающийся в том, что создают поток обновления и множество потоков поиска,назначают каждый из множества запросов на поиск, полученных через сеть, одному из множества потоков поиска,для каждого потока поиска: осуществляют поиск по базе данных в соответствии с назначенными запросами на поиск,создают множество ответов по поиску, соответствующих назначенным запросам на поиск, и посылают множество ответов по поиску через сеть, и-17 005646 для потока обновления: создают новый элемент в соответствии с новой информацией, полученной через сеть, и без ограничения доступа к базе данных для множества потоков поиска записывают указатель на новый элемент в базу данных с использованием одиночной непрерываемой операции. 22. Способ по п.21, отличающийся тем, что одиночная непрерываемая операция представляет собой команду сохранения. 23. Способ по п.21, отличающийся тем, что дополнительно для потока обновления физически удаляют существующий элемент после записи указателя в базу данных. 24. Способ по п.22, отличающийся тем, что команда сохранения записывает 4 байта в адрес памяти,размещенный на границе 4 байтов. 25. Способ по п.22, отличающийся тем, что команда сохранения записывает 8 байтов в адрес памяти, размещенный на границе 8 байтов. 26. Способ по п.21, отличающийся тем, что множество запросов на поиск принимают в одиночном пакете сети. 27. Способ по п.21, отличающийся тем, что множество ответов по поиску принимают в одиночном пакете сети. 28. Способ по п.21, отличающийся тем, что упомянутое ограничение доступа включает в себя блокировку базы данных. 29. Способ по п.21, отличающийся тем, что упомянутое ограничение доступа включает в себя взаимоблокировку. 30. Способ по п.29, отличающийся тем, что взаимоблокировка включает в себя использование, по меньшей мере, одного семафора. 31. Способ по п.30, отличающийся тем, что упомянутый семафор является семафором мьютекса. 32. Способ по п.21, отличающийся тем, что множество потоков поиска выполняют, по меньшей мере, 100000 поисков в секунду. 33. Способ по п.32, отличающийся тем, что поток обновления выполняет, по меньшей мере, 10000 обновлений в секунду. 34. Способ по п.33, отличающийся тем, что поток обновления выполняет от 50000 до 130000 обновлений в секунду. 35. Способ по п.21, отличающийся тем, что указатель на новый элемент записан в индекс поиска. 36. Способ по п.35, отличающийся тем, что индекс поиска представляет собой TST. 37. Способ по п.21, отличающийся тем, что указатель на новый элемент записан в запись данных в базе данных. 38. Носитель информации, считываемый компьютером, содержащий команды, предназначенные для выполнения, по меньшей мере, одним процессором, для выполнения способа поиска и параллельного обновления базы данных, включающего в себя создание потока обновления и множества потоков поиска,назначение каждого из множества запросов на поиск, полученных через сеть, одному из множества потоков поиска,для каждого потока поиска: осуществление поиска по базе данных в соответствии с назначенными запросами на поиск,создание множества ответов по поиску, соответствующих назначенным запросам на поиск, и передачу множества ответов по поиску через сеть, и для потока обновления: создание нового элемента в соответствии с новой информацией, полученной через сеть, и без ограничения доступа к базе данных для множества потоков поиска, запись указателя на новый элемент в базу данных с использованием одиночной непрерываемой операции. 39. Носитель информации, считываемый компьютером, по п.38, отличающийся тем, что одиночная непрерываемая операция представляет собой команду сохранения. 40. Носитель информации, считываемый компьютером, по п.38, отличающийся тем, что упомянутый способ для потока обновления дополнительно включает физическое удаление существующего элемента после записи указателя в базу данных. 41. Носитель информации, считываемый компьютером, по п.39, отличающийся тем, что команда сохранения записывает четыре байта в адрес памяти, размещенный на границе четырех байтов. 42. Носитель информации, считываемый компьютером, по п.39, отличающийся тем, что команда сохранения записывает восемь байтов в адрес памяти, размещенный на границе восьми байтов. 43. Носитель информации, считываемый компьютером, по п.38, отличающийся тем, что множество запросов на поиск принимают в одиночном пакете сети. 44. Носитель информации, считываемый компьютером, по п.38, отличающийся тем, что множество ответов по поиску передают в одиночном пакете сети. 45. Носитель информации, считываемый компьютером, по п.38, отличающийся тем, что ограничение доступа включает в себя блокировку базы данных.-18 005646 46. Носитель информации, считываемый компьютером, по п.38, отличающийся тем, что ограничение доступа включает в себя взаимоблокировку. 47. Носитель информации, считываемый компьютером, по п.46, отличающийся тем, что взаимоблокировка включает в себя использование, по меньшей мере, одного семафора. 48. Носитель информации, считываемый компьютером, по п.47, отличающийся тем, что семафор является семафором мьютекса. 49. Носитель информации, считываемый компьютером, по п.38, отличающийся тем, что указатель на новый элемент записан в индекс поиска. 50. Носитель информации, считываемый компьютером, по п.49, отличающийся тем, что индекс поиска представляет собой TST. 51. Носитель информации, считываемый компьютером, по п.38, отличающийся тем, что указатель на новый элемент записан в запись данных в базе данных. 52. Способ поиска и параллельного обновления базы данных, заключающийся в том, что создают поток обновления и множество потоков поиска,назначают каждый из множества запросов на поиск, полученных через сеть, одному из множества потоков поиска,для каждого потока поиска: осуществляют поиск по базе данных в соответствии с назначенными запросами на поиск,создают множество ответов по поиску, соответствующих назначенным запросам на поиск, и посылают множество ответов по поиску через сеть, и для потока обновления: без ограничения доступа к базе данных для множества потоков поиска, записывают указатель на существующий элемент в базу данных с использованием одиночной непрерываемой операции. 53. Способ по п.52, отличающийся тем, что указатель содержит нулевой указатель. 54. Способ по п.52, отличающийся тем, что дополнительно для потока обновления: физически удаляют существующий элемент после записи указателя в базу данных.
МПК / Метки
МПК: G06F 7/00
Метки: параллельным, база, данных, управлением, высокоскоростным
Код ссылки
<a href="https://eas.patents.su/24-5646-baza-dannyh-s-vysokoskorostnym-ne-parallelnym-upravleniem.html" rel="bookmark" title="База патентов Евразийского Союза">База данных с высокоскоростным не параллельным управлением</a>
Способ организации и хранения данных в базе данных и база данных
Номер патента: 5269
Опубликовано: 30.12.2004
Автор: Поли Дункан Г.
МПК: G06F 17/30
Метки: данных, способ, базе, хранения, база, организации
Формула / Реферат:
1. Способ организации хранения данных в базе данных (2), в котором конечные наборы данных (20, 24, 26, 28, 30, 40, 50, 60) для базы данных размещаются в иерархической структуре и в котором конечные наборы данных размещаются таким образом, что элементы данных вводятся в выбранный конечный набор данных на первом уровне значимости (уровень 1) до тех пор, пока число элементов данных не достигнет пороговой величины для выбранного конечного набора...
База данных (варианты) и способы организации базы данных (варианты)
Номер патента: 5641
Опубликовано: 28.04.2005
Автор: Поли Дункан Гюнтер
МПК: G06F 17/30
Метки: базы, организации, база, способы, варианты, данных
Формула / Реферат:
1. Способ организации базы данных, которая при использовании включает индекс (2) и данные (16), и в которой делается запрос по индексу (2), используя поисковый ключ, включающий по меньшей мере один символ, представленный множеством битов, чтобы найти данные, соответствующие критерию поиска, отличающийся тем, что индекс (2) - иерархическая структура узлов, которая передвигается во время поиска до тех пор, пока не будет получен конечный набор...
Способ сокращения объема памяти, требуемого базой данных для хранения данных, и создания базы данных
Номер патента: 1826
Опубликовано: 27.08.2001
Автор: Эль-Газзар Амин
МПК: G06F 17/30
Метки: сокращения, базой, способ, данных, памяти, создания, хранения, требуемого, объема, базы
Формула / Реферат:
1. Способ сокращения объема памяти, требуемого базой данных для хранения информации, отличающийся тем, что - сохраняемые единицы информации распределяют по точкам пересечения строк и столбцов, по меньшей мере, двумерной растровой матрицы, - размещенным в растровой матрице единицам информации присваивают индивидуальные координаты цвета и - сформированную таким путем матрицу изображения сохраняют в качестве базы данных или части базы данных. 2....
Лента данных и способ кодирования и декодирования печатных данных
Номер патента: 3380
Опубликовано: 24.04.2003
Авторы: Крюгер Тильманн, Бруггер Андреас, Майнерц Детлев, Вирнитцер Бернхард
МПК: G06K 19/06
Метки: кодирования, декодирования, способ, печатных, лента, данных
Формула / Реферат:
1. Лента данных для хранения в памяти печатных кодированных данных с высокой плотностью данных, причем заполненная печатными знаками поверхность ленты данных разделена на ячейки, и в одной двухмерной ячейке с заранее определенной формой напечатан каждый раз один из, как минимум двух, различных узоров с характеристической и заранее определенной формой, отличающаяся тем, что узоры имеют такие размеры, что они не разрешаются человеческим глазом, и...
Носитель данных с возможностью записи информации, имеющий участок защищенных данных
Номер патента: 4199
Опубликовано: 26.02.2004
Авторы: Калкер Антониус А., Линнартз Йохан П.М.Г., Талстра Йохан С.
МПК: G11B 20/00
Метки: защищенных, носитель, информации, возможностью, данных, имеющий, участок, записи
Формула / Реферат:
1. Способ сохранения данных на носителе данных с возможностью перезаписи, содержащем участок фиксированных данных с доступом только по чтению и участок записываемых данных, согласно которому системные данные хранят в участке записываемых данных, криптографическую итоговую информацию системных данных формируют и хранят в участке фиксированных данных и криптографическую итоговую информацию используют для проверки системных данных перед считыванием...
Предыдущий патент: Способ определения анизотропного электрического удельного сопротивления и угла падения пласта в геологической формации
Следующий патент: Битумная композиция с улучшенной “ходимостью” и ее использование в кровельных материалах
Случайный патент: Игровой автомат