LINUX.ORG.RU

Запустите один и тот же тест с набором типичных данных на разных SQL-серверах (PostgreSQL, MySQL, SQLite) и посмотрите, что вам больше подходит.

Andrey_Utkin ★★
()
Ответ на: комментарий от Andrey_Utkin

SQL тут не оверкилл? Тут же, по идее, только суммы накапливать надо. Какой-нибудь redis или memcached. А может, что нибудь еще проще.

JaneDoe
()
Ответ на: комментарий от JaneDoe

Если у автора напрашиваются формулировки в терминах SQL, то почему бы и нет? С обозначенной нагрузкой - не вижу проблем. Зачем оптимизировать производительность, если на практике производительность не стала проблемой?

Andrey_Utkin ★★
()
Ответ на: комментарий от Jopich

Это если хранить записи. А если просто накапливать суммы, то размер базы очень зависит от доменов field3 и field4. Вплоть до применимости awk и plain text. Ну тут да, тебе виднее.

JaneDoe
()

500-700 тыщ в день это мелочь. PostgreSQL если нужен именно SQL

quest ★★★★
()
Последнее исправление: quest (всего исправлений: 1)
apt install num-utils
$ cat columns 
1,6,11,16,21
2,7,12,17,22
3,8,13,18,23
4,9,14,19,24
5,10,15,20,25
$ numsum -s ',' -c columns
15 40 65 90 115

но у тебя не просто sum а еще group by, готовой тулзы я не знаю для такого. можно написать но нужно ли?

quest ★★★★
()

залей файлик на rghost.ru

quest ★★★★
()

от безделья написал тебе скрипт, создает временную базу и агрегирует:

$ cat data 
1,6,11,16
2,7,12,17
3,8,11,16
4,9,14,19
5,10,12,17

#/bin/sh

if [ ! -e "${1}" ];
then
    echo "example: ${0} FILE";
    exit 1;
fi

echo "CREATE TABLE tmp(field1 BIGINT, field2 BIGINT, field3 BIGINT, field4 BIGINT);";

while IFS=',' read -r field1 field2 field3 field4;
do
    echo "INSERT INTO tmp (field1, field2, field3, field4) values (${field1},${field2},${field3},${field4});";
done < "${1}";

echo "SELECT SUM(field1), SUM(field2), field3, field4 FROM tmp GROUP BY field3, field4;";

exit 0;
$ sh agregator.sh data | sqlite3 | sed -e 's/|/,/g'
4,14,11,16
7,17,12,17
4,9,14,19
quest ★★★★
()
Ответ на: комментарий от quest

от безделья

Неправильное у тебя безделье. Смотри как надо:

$ cat schema.awk
BEGIN {
    print "CREATE TABLE test (f1,f2,f3,f4);";
    
    for (i=0; i<1000000; i++)
        printf("INSERT INTO test VALUES(%f,%f,%f,%f);\n", rand(), rand(), rand(), rand());
}

$ time awk -f schema.awk | sqlite3 test.db
awk -f schema.awk  2.43s user 0.10s system 5% cpu 45.041 total
sqlite3 test.db  16.10s user 28.62s system 99% cpu 45.091 total

$ ls -lh test.db
-rw-r--r-- 1 user user 42M Apr 21 20:45 test.db

$ time sqlite3 test.db 'SELECT SUM(f1),SUM(f2) FROM test GROUP BY f3,f4;' > /dev/null
sqlite3 test.db 'SELECT SUM(f1),SUM(f2) FROM test GROUP BY f3,f4;' >   1.61s user 0.05s system 99% cpu 1.658 total

$ sqlite3 test.db 'SELECT SUM(f1),SUM(f2),SUM(f3),SUM(f4) FROM test;'
499927.249002986|499797.215621011|499835.673417987|500095.421166005
[/bash]

ТС, я тоже за sqlite. Главное всегда держать файл открытым, тогда будет работать шустро. На примере выше, заполнение 1М строк заняло 45 секунд на одном ядре. 'SUM() ... GROUP BY' по этим случайным данным считается за пару сек. Просто сумма всех четырёх полей на двух млн записях — 0.342 мсек.
anonymous
()
Ответ на: комментарий от quest

no problemo

$ sqlite3 test.db 'CREATE TABLE test (f1,f2,f3,f4);'

$ cat data \
  | awk -F ',' '{printf("INSERT INTO test VALUES(%f,%f,%f,%f);\n", $1,$2,$3,$4);}' \
  | sqlite3 test.db

А вам зачем?

anonymous
()

Вообще пофиг какую, 500-700 тысяч в день - это ерунда. Запрос суммирования делашь не в онлайне, а запускаешь периодически в фоне - нагрузка будет небольшая.

Короче, бери PostgreSQL - не ошибешься.

grondek
()
Последнее исправление: grondek (всего исправлений: 1)
Ответ на: комментарий от Jopich

700 000 записей по ссылке примерно 5 мегабайт. проверь, тут плюс в том что оно во временной таблице все делает, а так я везде postgresql использую

quest ★★★★
()
Ответ на: комментарий от anonymous

да, спасибо. я вчера полчаса потратил на поиск fast insert, способа заливки в таблицу и аналога COPY и так и не нашел.

quest ★★★★
()

Вообщем игры со всякими PRAGMA synchronous=OFF; PRAGMA journal_mode=MEMORY; PRAGMA temp_store=MEMORY; ничего не дали, вставка в транзакции то-же, создание индексов на таких объемах то-же. Самое большое время отжирал bash на создание INSERT и обработка sqlite INSERT.

$ cat agregator.sh 
#/bin/sh

if [ ! -e "${1}" ];
then
        echo "example: ${0} FILE";
        exit 1;
fi

echo "CREATE TABLE tmp(field1 BIGINT, field2 BIGINT, field3 BIGINT, field4 BIGINT);";

echo '.separator ","';

echo ".import ${1} tmp";

echo "SELECT SUM(field1), SUM(field2), field3, field4 FROM tmp GROUP BY field3, field4;";

exit 0;
$ time(sh agregator.sh ./data | sqlite3 | sed -e 's/|/,/g' &> /dev/null)

real    0m1.912s
user    0m1.864s
sys     0m0.020s

все равно уступает awk но универсальней)

quest ★★★★
()

Экзотический вариант — берешь HDF5 и PyTables как интерфейс и велосипедишь. HDF5 чем-то напоминает БД, по факту данные хранятся в виде таблиц или массивов. Сам HDF5 неплохо оптимизирован и фичаст (например, умеет весьма неплохое сжатие на лету), PyTables умеет быстро обрабатывать файлы размером значительно больше объема оперативной памяти. Так как это заточено под математику, в твоем случае должно работать быстрее, чем реляционные БД.

Впрочем, большой недостаток — в этом надо разбираться (очевидно, оно не поддерживает SQL), кроме того, на 500к записях в день прирост скорости вряд ли будет сильно заметен. Вот если бы записей было на порядка два больше...

lu4nik ★★★
()
Ответ на: комментарий от anonymous

begin/end transaсtion использовали?

У меня в старом проекте 300K-600K записей меньше чем за 30c вставлялось (iPhone 4S).

necromant ★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.