Я трогал.
Это так называемая edge database, подкласс гибридных "in-memory" ( http://www.dbta.com/frontpage_archives/1-04.html ) , которая заточена на очень быстрое выполнение транзакций при всех данных размещенных (желательно) в памяти. Это НЕ enterprice database (Sybase ASE, Oracle, DB2, Informix, MS SQL) и я не считаю идею вашего начальства хорошей. ANTs, как я понял, годится либо для встраивания в девайсы, либо как супербыстрая OLTP для небольших объемов данных.

В таком вот аксепте

iscrafm ВыбегаллоЯ трогал.
Это так называемая edge database, подкласс гибридных "in-memory" ( http://www.dbta.com/frontpage_archives/1-04.html ) , которая заточена на очень быстрое выполнение транзакций при всех данных размещенных (желательно) в памяти. Это НЕ enterprice database (Sybase ASE, Oracle, DB2, Informix, MS SQL) и я не считаю идею вашего начальства хорошей. ANTs, как я понял, годится либо для встраивания в девайсы, либо как супербыстрая OLTP для небольших объемов данных.
В таком вот аксепте
Видимо не поняли. Во-первых ADS не является IN-MEMORY базой, если бы Вы трогали, то поняли бы это. Во-вторых, все последующие Ваши выводы ложные, т.к. сделаны на ошибочном первом.

2 Zhora
---
Мы сейчас крутим этот сервер на предмет применения в проектах. Одна из основных его фишек - способ использования многопроцессорных машин, он заточен на работу с несколькими процессорами. Множество диалектов привлекает. Полное отсутствие администрирования, запустил и забыл. На каждую таблицу - свой файл, если это интересно. Клиентских интерфейсов нет. WinSQL используем в качестве такового. В общем, сервер в чистом виде :)
Я думаю Вам лучше установить и попробовать на своих данных, тем более портировать с указанных Вами СУБД не проблема. Реально увидите - шило на мыло или явный выигрыш.

Это не чистая "in-memory" database, но заточенная именно под такое применение. Поэтому я сильно сомневаюсь в качестве ее оптимизатора, умении распараллеливать запросы или там фрагментировать данные по разным файлам.
А "использование многопроцессорных машин" - это, извиняюсь, только для фокса "фишка". Все enterprice level databases (Sybase, Oracle, DB2, Informix, MS SQL) эту "фишку" имеют уже десять - пятнадцать лет.
И про "клиентских интерфейсов нет" это вы загнули - это только MUMS может без ODBC обходиться. ODBC, JDBC, SNMP, утилита командной строки, performance monitor, парсер намониторенного - все в наличии.

iscrafm
Выбегалло
Это не чистая "in-memory" database, но заточенная именно под такое применение.

Вот этого теперь я не понял. Что означает "заточенный под in-memory применение"?


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

Интересные конфигурационные параметры :
MAXROWS - If this optional parameter is specified, no table (except for ANTs Data Server system tables) will be allowed to exceed this many rows.

MAXROWCOUNT (25000 default) - The limit on the number of rows in each table
which will be retained in updateable format within the ANTs Data Server. The largest permitted value for this parameter is 2,000,000.

И по поводу использования многопроцессорных машин я бы не обольщался.
Рекомендации для IPC клиентов (клиентов, выполняемых на той же машине где сервер)
By default, the ANTs Data Server makes use of all physical processors in the server machine, which can actually reduce performance if clients are attempting to run on the same machine. To prevent the ANTs Data Server from doing this, the ANTs Data Server “CPU_CONFIGURATION” parameter in the config.txt file should be set. Best performance will usually be obtained by reserving most CPUs for client
processing; the ANTs Data Server will usually need less than half of all CPUs to keep up with client demands.The recommended settings are:
If your computer has
this many CPUs Set the CPU_CONFIGURATION to
1 Leave at the default value. Good performance
cannot be expected in this case, although testing
for functionality can be done.
2 1
4 1
8 3
more than 8 Half, or slightly less than half, of all CPUs

так что для 4 CPU они почему-то советуют использовать 1 (один) процессор.

iscrafmCPU_CONFIG...
А что Вас смутило. Меня например именно в том, что Вы привели - ничего. ADS использует все доступные процессоры если укажете. На серверах рекомендуют оставлять 1 для работы ОС, сетевых протоколов и т.п. Если в режиме колокейшн, то разработчик привел таблицу настройки количества процессоров при которой получается наименьшее время отклика. Почему оно на 4-х проц. машине получается при использовании 1 процессора? Факт интересный, но не более.


Это косвенный показатель высоких накладных расходов на организацию межпроцессорного взаимодействия. Скажем, для информикса рекомендации такие :
For multiprocessor systems with four or more CPUs that are primarily used as database servers, Informix recommends that you set NUMCPUVPS to one less than the total number of processors . When you use this setting, one processor is available to run the database server utilities or the client application.
For multiprocessor systems that you do not use primarily to support database servers, you can start with somewhat fewer CPU VPs to allow for other activities on the system and then gradually add more if necessary.


iscrafm авторЭто значит, что оптимизатор предпочитает считать, что данные уже находятся в памяти. Поэтому код написан под максимальное быстродействие в памяти - ну блокировки там всякие, латчи, локи, списки - и не особо заботится про ускорение работы с диском. Оптимизатор не перебирает сильно много вариантов, чтобы перебор не занял больше времени чем тупое выполнение в лоб - если все данные в памяти, то разница между хорошим и плохим вариантами окажется невелика. Сложные запросы не распараллеливаются.
К сож. не имею информации как у него устроен оптимизатор, не публикуют. Если у Вас есть ссылка на такую информацию поделитесь плз. Хотя они везде акцентируют внимание именно на том, что это дисковая база с IN-MEMORY скоростью.

Устойство оптимизатора - самый охраняемый секрет коммерческой БД, так что не надейтесь на подробности. "дисковая база с IN-MEMORY скоростью" - маркетинговый слоган, ничего общего с реалиями не имеющий. Расскажите мне, как дисковая база может иметь in-memory скорость, если скорость обращения к диску на несколько порядков ниже скорости обращения к памяти.



авторЕдинственный тип индекса.
Не доставляет каких-либо неудобств. А сколько типов нужно? И с какой целью эти типы придумываются?[/quot]

Разные индексы нужны для а) разных типов запросов, б) разных типов данных в) разных распределений уникальных значений и г) разных режимов работы. Скажем, Sybase IQ admin guide пишет
-----
Traditional indexes use a B-tree index strategy to point to the data records. That
strategy is valuable only if many unique data values are used to filter down
to a very small set of records, as with columns of order numbers or
customer names, as you would encounter in a transaction processing
system.
Adaptive Server IQ indexes actually represent and store the data so that
the data can be used for processing queries. This strategy is designed for
the data warehousing environment , in which queries typically examine
enormous numbers of records, often with relatively few unique values,
and in which aggregate results are commonly required.

Имеющиеся типы индексов (причем можно создавать индексы разных типов на одной и той же колонке)
To achieve maximum query performance, however, you should choose one or
more additional index types for most columns that best represent the
cardinality and usage of column data:
• Compare or CMP Stores the binary comparison (<, >, or =) of any two
distinct columns with identical data types, precision, and scale.
• DATE An index on columns of data type DATE used to process queries
involving date quantities.
• Datetime or DTTM An index on columns of data type DATETIME or
TIMESTAMP used to process queries involving datetime quantities.
• High_Group or HG An enhanced b-tree index to process equality and
group by operations on high-cardinality data (recommended for more than
1,000 distinct values)
• High_Non_Group or HNG A non value-based bitmap index ideal for
most high-cardinality DSS operations involving ranges or aggregates
Low_Fast or LF A value-based bitmap for processing queries on lowcardinality
data (recommended for up to 1,000 distinct values. Can support
up to 10,000 distinct values.)
• TIME An index on columns of data type TIME used to process queries
involving time quantities.
• WD Used to index keywords by treating the contents of a CHAR or
VARCHAR column as a delimited list.

информикс позволяет создавать собственный тип индекса для собственнго типа данных. CopperEye недавно придумало новый тип индекса, доступный через datablade, для real-time и near real-time систем :
-----------
The company provides what it calls adaptive indexing. Basically, this means faster performance for large, disk-based, general-purpose indexing. In the laboratory, testing showed performance improvements of as much as ten times while the beta site found four times real-life improvements (which is an interesting comment on the distinction between benchmarks and the real world). Nevertheless, which ever way you slice it, that is a significant improvement.

However, Adaptive Indexing isn't just about go faster indexing: it isn't called adaptive for nothing. In practice, you can decide what you want to optimise the indexing for, whether for retrieval or update or a mix of the two.
------------

Ну и еще раз напоминаю, что без эффективной фрагментизации таблиц (разнесения их по разным файлам), причем с разными алгоритмами разнесения, невозможно эффективно работать с большими объемами данных - ни параллельное чтение не запустишь, ни fragment elimination не используешь.

iscrafm Выбегалло Расскажите мне, как дисковая база может иметь in-memory скорость, если скорость обращения к диску на несколько порядков ниже скорости обращения к памяти.
За счет алгоритмов минимизации таких обращений. Хорошее(правильное, оптимальное) распределение данных между памятью и диском - разве не здесь простор для инноваций?


Стандартный процент чтения из кеша у Информикса - 98-99. Запись - 90-95%. Где вы видите потециал коренным образом улучшить эти значения, кроме как всосать все данные в память и держать их там ? Правда, есть маленькое "но" - данных должно быть не больше, чем имеющейся памяти.

iscrafm Выбегаллоset NUMCPUVPS to one less than the total number of processors.
Вроде тоже самое пишут.


При 4 процессорах informix рекомендует использовать 2 или 3, ANTs - 1.

iscrafm ВыбегаллоРазные индексы нужны для а) разных типов запросов, б) разных типов данных в) разных распределений уникальных значений и г) разных режимов работы
Видите ли в чем вопрос: это поиск стратегии к посмертным данным. Тут можно хоть обыскаться и придумывать индексы на каждую 31-ю или 90-ю запись. Кто ,во что горазд. Меня просто сейчас более интересуют живые данные компаний.[/quot]

Зря я тут бисер мечу...