Более общественная задачка компов - работа с информацией. А самый стремительный метод получить информацию - отыскать ее по определенному параметру (по ассоциации). Но компьютерная память имеет не ассоциативную, а адресную структуру, а cуществующие методы ускорения доступа (сортировка, индексирование, хеширование) по сути - просто создание на уровне программного обеспечения виртуальной ассоциативной памяти.
А что, ежели для конструктивного ускорения работы сделать плату расширения, которая работала бы ассоциативной памятью? Нужна ли ассоциативная память? Мир захлестнула волна инфы. И чтоб отыскать в этом потоке то, что нам необходимо, нужны средства для скорого поиска и подборки инфы. Обычно, информация хранится в виде баз данных, которые, в том либо ином виде, стоят на данный момент практически на каждом компе. Так как традиционно базы данных есть в виде таблиц, стоит начать с рассмотрения обычной структуры таблицы в реляционной базе данных. Все поля, входящие в таблицу, можно разбить на три группы: системные поля, поля наименования, и поля данных. Системные поля - это ключи. В их входят первичный ключ (счетчик) для связи с подчиненными таблицами и вторичные ключи для связи с главными таблицами (ежели данная таблица является подчиненной). Поля данных - в их хранятся данные о объекте. Это поля типа числовые, валютные, дата/время, и т.д. Поля наименования - это те поля, по которым юзер может идентифицировать описанный в таблице объект в ряду для себя схожих. Для предотвращения дублирования записей (т.е. возникновения "двойников") нужно обеспечивать неповторимость записей. Типы полей - строковые, реже - числовые либо дата/время. При работе с таблицей одна из основных задач - подборка , при этом почти всегда подборка осуществляется по параметру (другими словами из таблицы выбираются лишь те записи, которые соответствуют некому условию). Есть два подхода к выборке: "сверху", со стороны юзеров, и "снизу", со стороны аппаратного обеспечения ("железа"). При подходе "сверху" основной определяющий фактор - удобство юзера . Существует много методов доступа к данным в таблицах, но наибольшее распространение получил язык SQL. Практически SQL практически стал индустриальным эталоном для реляционных баз данных. Южноамериканский Институт Государственных Стандартов (ANSI) в 1986 году объявил язык SQL эталоном для реляционных баз данных. То же самое сделала и Интернациональная Организация по эталонам (ISO). Все главные реляционные системы управления баз данных поддерживают в том либо ином виде язык SQL, и большая часть разрабов реляционных систем управления базами данных стремятся следовать эталону ANSI ([1], глава 2, стр. 4). Конструкторы SQL интегрированы в настольные СУБД (ACCESS, Delphi), серверные приложения работают в основном с SQL (ORACLE, SQL server). При подходе "снизу" основной определяющий фактор - архитектура компа . В текущее время компы имеют адресную структуру памяти и адаптированы для операций "не достаточно данных - много команд", а при работе с данными (при выборке) почаще всего происходят операции типа "много данных - не много команд" Произошедшее за ближайшее время бурное развитие компьютерной техники не только лишь не решило, а быстрее ухудшило эту делему. Производительность процессоров возросло во много раз, возросла емкость винчестеров и размер оперативной памяти. А вот производительность канала память - процессор возросла чрезвычайно некординально, и является на этот момент камнем преткновения. Применение аппаратных средств ускорения (кэширования) тоже не чрезвычайно отлично из-за огромных размеров данных. В команде SQL указывается сама команда (действие, которое нужно совершить), область подборки (таблицы, из которых нужно произвести подборку), данные, которые должны быть выданы (перечень полей), условия связи меж таблицами и условия отбора, другими словами по команде SQL практически осуществляется ассоциативная подборка из базы данных. Для того, чтоб получить доступ к подходящей записи в таблице нужно или перебирать все записи (для этого будет нужно N циклов, N - число записей в таблице), или отыскать адресок записи (потому что память компа имеет адресную архитектуру). Для ускорения поиска прилагаются огромные усилия: используют сортировки (другими словами записи упорядочивают в определенном порядке), индексирование, и хеширование (адресок записи - некая функция от значения аргумента записи). Разглядим подробнее все эти методы. При дихотомическом поиске в упорядоченном массиве количество циклов поиска - log2 N, где N - число записей в таблице. Но сортировки создают лишь по одному полю. Опосля совершения хоть какого деяния над записями (прибавления, конфигурации, удаления) приходится создавать упорядочивание (пересортировку) таблицы, а число перестановок растет в геометрической прогрессии при увеличении количества записей. Потому индексация таблиц не чрезвычайно помогает: индексы занимают место (а время от времени могут превосходить размеры таблиц), не считая того, они не помогают в случае отбора по неиндексированному полю. Индексы - это особые конструкции, которые разрешают быстро отыскать адресок подходящей записи и в текущее время они обширно используются на практике. На одну таблицу можно создавать несколько индексов. В качестве примера можно разглядеть советы по применению индексов в ORACLE ([1], глава 18, стр. 14). Они сводятся к последующему: рекомендуется употреблять индексы для обеспечения уникальности записей; для ускорения подборки данных; задавать индексы для тех полей, подборку по которым делается почаще всего, и при всем этом рекомендуется задавать на таблицу менее 3 индексов, что чрезвычайно не много. На практике используют индексы последующим образом: в системных полях таблиц употребляют 1-2 индекса, и очередной индекс - на поля наименования. Область данных практически никогда не индексируют, хотя отбор почаще всего происходит конкретно по сиим полям ([1], глава 2, стр. 22-33, глава 3, стр. 3). Не считая того, обновление индексов также просит времени, а сами индексы занимают место на диске (а время от времени размер индексов превосходит размер основной таблицы). При хешировании записей под таблицу сходу выделяют с запасом некий размер памяти, и адресок записи в этом объеме - некая функция от содержимого 1-го из полей записи (хеш-функция). Хеширование также проводят по одному полю. Недочеты этого метода: необходимость в лишнем резервировании памяти. Не считая этого, даже при довольно большом выделенном объеме памяти возможна ситуация, при котором на некое место претендуют сходу две либо наиболее записей, другими словами возникает коллизия. Неувязка скорого доступа к данным на машинках с адресной памятью до этого времени не решена. При работе с адресной памятью тяжело достигнуть существенного увеличения скорости доступа на аппаратном уровне, потому что при обращении к памяти постоянно нужно указывать адресок данных, и за один цикл можно обратиться лишь к одной ячейке памяти [2, стр. 152]. В текущее время ускорение доступа происходит благодаря программному обеспечению, которое практически делает виртуальную ассоциативную память на машинках с адресной памятью, что не чрезвычайно отлично. Потому что устройство с ассоциативной памятью создано для увеличения скорости доступа при работе с базами данных, то более целенаправлено выполнить его в виде отдельной платы расширения для компа. Потом на основании данной для нас платы быть может сотворен сопроцессор данных (SQL-сопроцессор). Значительно повысить скорость доступа к данным можно ежели включить в состав компа память с адресацией по содержанию (ассоциативной памяти). Применение ассоциативной памяти дозволяет значительно повысить скорость подборки и упростить доступ к данным. Потому что при выборке происходит ряд логических операций по отбору данных, то отпадает необходимость в особых программных конструкциях по ускорению доступа: сортировках и хешировании, а индексы потребуются лишь для обеспечения уникальности записей и задания связей меж таблицами. Уже сотворен ряд микросхем ассоциативной памяти, их применение дозволяет значительно повысить производительность. Возможность адресного и ассоциативного доступа к хранящимся в памяти данным. Адресный доступ нужен для того, чтоб можно было бы работать с определенной записью. Не считая того, при наличии адресного доступа становится вероятным внедрение библиотек тестов, разработанных для адресной памяти. Модульная конструкция памяти. Потому что заблаговременно нереально найти круг задач, решаемых устройством, то ассоциативная память обязана быть очень гибкой и допускать возможность опции для решения разных задач. Плата расширения быть может применена для увеличения производительности серверов (за счет обработки инфы на шаге считывания из памяти, также уменьшения перегрузки на шины) баз данных типа ORACLE и SQL SERVER, расположенных на машинках x86, также для обработки графики, при всем этом применение платы расширения обязано быть оправдано по аспекту "стоимость - эффективность" (другими словами применение платы стоимостью 100-200$ приводит к повышению производительности машинки раза в полтора). Устройство управления ассоциативной памятью обязано с помощью микропрограмм делать более 90% запросов, направляемых к памяти. В других вариантах с памятью работают как с обыкновенной адресной памятью, либо создают подборку на базе имеющихся микропрограмм с следующей обработкой результатов. В дополнение к этому, станет неосуществимым несанкционированное копирование программ. Потому что при работе программы повсевременно происходит обращение к плате расширения, то без нее программа просто не запустится либо будет работать в демо-режиме с надлежащими ограничениями. При всем этом количество сразу работающих программ ограничено количеством устройств. Вообщем, стоит отметить, что внедрение особых аппаратных средств для увеличения производительности компа при выполнении узкоспециализированных задач - довольно обычный подход к решению задачи. Ежели вспомнить историю, то сначала 80-х годов для ускорения расчетов был сотворен математический сопроцессор, а посреди 90-х для ускорения вывода графики - 3D ускоритель (видеопроцессор). Кохонен Т. "Ассоциативные запоминающие устройства". Москва, "Мир", 1982 г. Учебное пособие "Введение в Oracle: SQL, SQL*Plus, и PL/Plus". Комменты? Поправки? Дополнения? Версия 1.9
А что, ежели для конструктивного ускорения работы сделать плату расширения, которая работала бы ассоциативной памятью? Нужна ли ассоциативная память? Мир захлестнула волна инфы. И чтоб отыскать в этом потоке то, что нам необходимо, нужны средства для скорого поиска и подборки инфы. Обычно, информация хранится в виде баз данных, которые, в том либо ином виде, стоят на данный момент практически на каждом компе. Так как традиционно базы данных есть в виде таблиц, стоит начать с рассмотрения обычной структуры таблицы в реляционной базе данных. Все поля, входящие в таблицу, можно разбить на три группы: системные поля, поля наименования, и поля данных. Системные поля - это ключи. В их входят первичный ключ (счетчик) для связи с подчиненными таблицами и вторичные ключи для связи с главными таблицами (ежели данная таблица является подчиненной). Поля данных - в их хранятся данные о объекте. Это поля типа числовые, валютные, дата/время, и т.д. Поля наименования - это те поля, по которым юзер может идентифицировать описанный в таблице объект в ряду для себя схожих. Для предотвращения дублирования записей (т.е. возникновения "двойников") нужно обеспечивать неповторимость записей. Типы полей - строковые, реже - числовые либо дата/время. При работе с таблицей одна из основных задач - подборка , при этом почти всегда подборка осуществляется по параметру (другими словами из таблицы выбираются лишь те записи, которые соответствуют некому условию). Есть два подхода к выборке: "сверху", со стороны юзеров, и "снизу", со стороны аппаратного обеспечения ("железа"). При подходе "сверху" основной определяющий фактор - удобство юзера . Существует много методов доступа к данным в таблицах, но наибольшее распространение получил язык SQL. Практически SQL практически стал индустриальным эталоном для реляционных баз данных. Южноамериканский Институт Государственных Стандартов (ANSI) в 1986 году объявил язык SQL эталоном для реляционных баз данных. То же самое сделала и Интернациональная Организация по эталонам (ISO). Все главные реляционные системы управления баз данных поддерживают в том либо ином виде язык SQL, и большая часть разрабов реляционных систем управления базами данных стремятся следовать эталону ANSI ([1], глава 2, стр. 4). Конструкторы SQL интегрированы в настольные СУБД (ACCESS, Delphi), серверные приложения работают в основном с SQL (ORACLE, SQL server). При подходе "снизу" основной определяющий фактор - архитектура компа . В текущее время компы имеют адресную структуру памяти и адаптированы для операций "не достаточно данных - много команд", а при работе с данными (при выборке) почаще всего происходят операции типа "много данных - не много команд" Произошедшее за ближайшее время бурное развитие компьютерной техники не только лишь не решило, а быстрее ухудшило эту делему. Производительность процессоров возросло во много раз, возросла емкость винчестеров и размер оперативной памяти. А вот производительность канала память - процессор возросла чрезвычайно некординально, и является на этот момент камнем преткновения. Применение аппаратных средств ускорения (кэширования) тоже не чрезвычайно отлично из-за огромных размеров данных. В команде SQL указывается сама команда (действие, которое нужно совершить), область подборки (таблицы, из которых нужно произвести подборку), данные, которые должны быть выданы (перечень полей), условия связи меж таблицами и условия отбора, другими словами по команде SQL практически осуществляется ассоциативная подборка из базы данных. Для того, чтоб получить доступ к подходящей записи в таблице нужно или перебирать все записи (для этого будет нужно N циклов, N - число записей в таблице), или отыскать адресок записи (потому что память компа имеет адресную архитектуру). Для ускорения поиска прилагаются огромные усилия: используют сортировки (другими словами записи упорядочивают в определенном порядке), индексирование, и хеширование (адресок записи - некая функция от значения аргумента записи). Разглядим подробнее все эти методы. При дихотомическом поиске в упорядоченном массиве количество циклов поиска - log2 N, где N - число записей в таблице. Но сортировки создают лишь по одному полю. Опосля совершения хоть какого деяния над записями (прибавления, конфигурации, удаления) приходится создавать упорядочивание (пересортировку) таблицы, а число перестановок растет в геометрической прогрессии при увеличении количества записей. Потому индексация таблиц не чрезвычайно помогает: индексы занимают место (а время от времени могут превосходить размеры таблиц), не считая того, они не помогают в случае отбора по неиндексированному полю. Индексы - это особые конструкции, которые разрешают быстро отыскать адресок подходящей записи и в текущее время они обширно используются на практике. На одну таблицу можно создавать несколько индексов. В качестве примера можно разглядеть советы по применению индексов в ORACLE ([1], глава 18, стр. 14). Они сводятся к последующему: рекомендуется употреблять индексы для обеспечения уникальности записей; для ускорения подборки данных; задавать индексы для тех полей, подборку по которым делается почаще всего, и при всем этом рекомендуется задавать на таблицу менее 3 индексов, что чрезвычайно не много. На практике используют индексы последующим образом: в системных полях таблиц употребляют 1-2 индекса, и очередной индекс - на поля наименования. Область данных практически никогда не индексируют, хотя отбор почаще всего происходит конкретно по сиим полям ([1], глава 2, стр. 22-33, глава 3, стр. 3). Не считая того, обновление индексов также просит времени, а сами индексы занимают место на диске (а время от времени размер индексов превосходит размер основной таблицы). При хешировании записей под таблицу сходу выделяют с запасом некий размер памяти, и адресок записи в этом объеме - некая функция от содержимого 1-го из полей записи (хеш-функция). Хеширование также проводят по одному полю. Недочеты этого метода: необходимость в лишнем резервировании памяти. Не считая этого, даже при довольно большом выделенном объеме памяти возможна ситуация, при котором на некое место претендуют сходу две либо наиболее записей, другими словами возникает коллизия. Неувязка скорого доступа к данным на машинках с адресной памятью до этого времени не решена. При работе с адресной памятью тяжело достигнуть существенного увеличения скорости доступа на аппаратном уровне, потому что при обращении к памяти постоянно нужно указывать адресок данных, и за один цикл можно обратиться лишь к одной ячейке памяти [2, стр. 152]. В текущее время ускорение доступа происходит благодаря программному обеспечению, которое практически делает виртуальную ассоциативную память на машинках с адресной памятью, что не чрезвычайно отлично. Потому что устройство с ассоциативной памятью создано для увеличения скорости доступа при работе с базами данных, то более целенаправлено выполнить его в виде отдельной платы расширения для компа. Потом на основании данной для нас платы быть может сотворен сопроцессор данных (SQL-сопроцессор). Значительно повысить скорость доступа к данным можно ежели включить в состав компа память с адресацией по содержанию (ассоциативной памяти). Применение ассоциативной памяти дозволяет значительно повысить скорость подборки и упростить доступ к данным. Потому что при выборке происходит ряд логических операций по отбору данных, то отпадает необходимость в особых программных конструкциях по ускорению доступа: сортировках и хешировании, а индексы потребуются лишь для обеспечения уникальности записей и задания связей меж таблицами. Уже сотворен ряд микросхем ассоциативной памяти, их применение дозволяет значительно повысить производительность. Возможность адресного и ассоциативного доступа к хранящимся в памяти данным. Адресный доступ нужен для того, чтоб можно было бы работать с определенной записью. Не считая того, при наличии адресного доступа становится вероятным внедрение библиотек тестов, разработанных для адресной памяти. Модульная конструкция памяти. Потому что заблаговременно нереально найти круг задач, решаемых устройством, то ассоциативная память обязана быть очень гибкой и допускать возможность опции для решения разных задач. Плата расширения быть может применена для увеличения производительности серверов (за счет обработки инфы на шаге считывания из памяти, также уменьшения перегрузки на шины) баз данных типа ORACLE и SQL SERVER, расположенных на машинках x86, также для обработки графики, при всем этом применение платы расширения обязано быть оправдано по аспекту "стоимость - эффективность" (другими словами применение платы стоимостью 100-200$ приводит к повышению производительности машинки раза в полтора). Устройство управления ассоциативной памятью обязано с помощью микропрограмм делать более 90% запросов, направляемых к памяти. В других вариантах с памятью работают как с обыкновенной адресной памятью, либо создают подборку на базе имеющихся микропрограмм с следующей обработкой результатов. В дополнение к этому, станет неосуществимым несанкционированное копирование программ. Потому что при работе программы повсевременно происходит обращение к плате расширения, то без нее программа просто не запустится либо будет работать в демо-режиме с надлежащими ограничениями. При всем этом количество сразу работающих программ ограничено количеством устройств. Вообщем, стоит отметить, что внедрение особых аппаратных средств для увеличения производительности компа при выполнении узкоспециализированных задач - довольно обычный подход к решению задачи. Ежели вспомнить историю, то сначала 80-х годов для ускорения расчетов был сотворен математический сопроцессор, а посреди 90-х для ускорения вывода графики - 3D ускоритель (видеопроцессор). Кохонен Т. "Ассоциативные запоминающие устройства". Москва, "Мир", 1982 г. Учебное пособие "Введение в Oracle: SQL, SQL*Plus, и PL/Plus". Комменты? Поправки? Дополнения? Версия 1.9