[evpu]

>>а можно в одном запросе послать не 1 INSERT а сразу кучу (15-20 и более)? »
>Можно, «INSERT INTO … SELECT … FROM …». Но, как я понимаю, Вам это не подойдёт.

Кое в чем подойдет. Перспектива тратить на 1 вставку (или что угодно другое) аж целый запрос - ИМХО жирно. Полагаю, что СУБД прекрасно в состоянии отработать одновременно 20-30 фраз, которые можно впихать в один запрос. Поправьте, если я не прав... буду пробовать.

>>Так вот, будет вставлено только две записи по первому и второму запросам. А по третьему и четвёртому — вставка записи будет отвергнута, поскольку недопустимо дублирование первичного ключа.

Это проверил - работает на MySQL! Уже хорошо!

Подскажите еще по одному - так таки если таблица будет иметь указанный чудовищный размер (сотни миллиардов строк) - будет ли разумным время ответа при формировании из нее небольшой выборки?

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

[lxa85]

evpu, ну так, рекламы для facebook-presto
Чисто для покурить поискать слова и спрятанные за ними технологии.

Короче... »

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

Подскажите еще по одному - так таки если таблица будет иметь указанный чудовищный размер (сотни миллиардов строк) - будет ли разумным время ответа при формировании из нее небольшой выборки? »

Если эта таблица поместиться на быстродействующую память, то будет. А нет-нет.
Исхожу из статьи, посвященному обработке гигабайтных баз данных под MapReduce что ли.
Вывод был таков: если БД помещается в оперативку, или на SSD накопитель, то пользуйте PostgreSQL все нормально. А вот если оно туда не влазит, то это уже можно попробовать назвать BigData и думать над соотв. инструментом.
Т.ч. если этим сотни миллиардов строк уложатся пусть в пусть 100Gb пространства, то SSD - снивилирует эту проблему.
Бекап понятно ленты, диски. Но это уже другой вопрос.

[Iska]

Кое в чем подойдет. Перспектива тратить на 1 вставку (или что угодно другое) аж целый запрос - ИМХО жирно. Полагаю, что СУБД прекрасно в состоянии отработать одновременно 20-30 фраз, которые можно впихать в один запрос. Поправьте, если я не прав... буду пробовать. »

Тот синтаксис предназначен для добавления записей в таблицу, извлечённых из другой таблицы. И диалект я привёл, разумеется, для Jet.

«Перспектива тратить на 1 вставку…» — это вполне нормально. Вспомните, что ядро базы должно при этом отработать все триггеры: каждого поля, всей записи, всех ключей, целостности базы.

Подскажите еще по одному - так таки если таблица будет иметь указанный чудовищный размер (сотни миллиардов строк) - будет ли разумным время ответа при формировании из нее небольшой выборки? »

Сейчас у Вас сколько примерно строк?

[Iska]

lxa85, небольшая выборка — это и значит небольшая выборка. Поиск должен будет вестись только по индексам, а не по:

сотни миллиардов строк »

100Gb »

И извлекаться будут не все эти объёмы. Хотя, как я понимаю, даже три longint (Jet) или bigint (MS SQL) плюс один double — размер строки основной таблицы, если действительно «место» и «человек» могут повторяться и обязаны быть вынесены в отдельные таблицы, займёт несколько больше 100 Gb.

[evpu]

>>Сейчас у Вас сколько примерно строк?

За 100000 перевалило... Время запроса произвольной строки около 10-20мс.


Извиняюсь за офтоп... Тут задачка для первокласника... Вот есть функция sscanf() производящая форматированный ввод из строки. Конкретнее пример:
sscanf("192.168.1.1 root jgjFGHjhj 20000 0", "%s %s %s %s %s", ip, login, pass, listen, sqlport );

Приведенаня строка на самом деле - читается из файла.... Но "192.168.1.1 root jgjFGHjhj 20000 0" это неудобно, хотелось бы настроить форматированный ввод типа:

"<ip>192.168.1.1</ip> <login>root</login> <pass>jgjFGHjhj</pass> <listen>20000</listen> <sqlport>0</sqlport>".

Вот сохранять конфиг в таком виде - совершенно очевидно элементарно может sprintf(). Подскажите - как отформатировать подобный ввод?

[evpu]

Добрый день!

По данной теме, пришел к решению, писать данные во временную таблицу temp_log, с последующим переносом в основную - stat_tab, именно она будет распухать.

Для переноса соорудил конструкцию:

INSERT INTO stat_tab SELECT * FROM temp_log WHERE `flag` = '1' ;

(флаг=1 - копируются записи, прошедшие транзакционную обработку.)

Вопрос - как соорудить команду, чтобы в процессе запроса помимо всего прочего, строка после вставки удалялась из temp_log?

[Greshnick]

Доброго времени суток. Вопрос в к Вам как раз по поводу оптимизации текст по ссылке http://forum.oszone.net/thread-304322.html. И вообще где можно прочитать о зависимости аппаратного обеспечения на показатели тестирования какие будут идеальны. А какие уж очень ужасны.

[evpu]

Да, тут речь идет о хранимых процедурах, как раз оно! На таком решении и сделал!

Это вообще БОМБА! Когда создавал эту тему - и предполагал об этом подсознательно... Там и внутрисерверные циклы, и все что угодно.


Только модифицировать пришлось:
INSERT INTO stat_tab SELECT `id`=0,``...()весь длиннющий перечень...`` FROM temp_log WHERE `flag` = '1' ;
TRUNCATE temp_log;
И далее всякие COMMIT и т.п.

Модификация потому, чтобы idшники пересчитывались в новую таблицу.

[User001]

Посоветуйте про какие операторы мануалы изучать?)) »

Вроде, про профилировку никто еще не сказал. Сюда и далее по поиску.

[evpu]

Кстати да... Спасибо, поюзаю!

>>какие будут идеальны. А какие уж очень ужасны.
Тут сказать сложно... Но например - я взял SSD, на его базе поднял linux-apache-mysql-php (LAMP), и там же исполняется бинарник написанный на С.
Так скажем - отличие РАДИКАЛЬНОЕ от Денверов и девелоперских конфигураций - на порядок. Я как будто только успеваю отправить запрос - как мне выплевывает ответ, несмотря на кучу запросов. А конфигурация тем не менее проста и бесхитростна - core2duo 8400 3GHz, RAM 3GB, SSD накопитель.