Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Firebird, InterBase Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 46 47 48 49 50 51 [52] 53 54 55   вперед  Ctrl
 Re: Конкурс идей про Firebird  [new]
Basil A. Sidorov
Member

Откуда:
Сообщений: 10418
zigorzn
удобно для перехода между версиями : gbak ..-c .. <БДисточник2.5> ... <БД3.0>
Оригинал или перевод.

P.S.
Под виндой можно работать и через xnet://, но, обычно, конвертация это простой, поэтому не надо выделываться с сервером - используйте embedded-режим.
13 дек 19, 20:11    [22040209]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 29015
Basil A. Sidorov,

а, я забыл, что на русском на хабре уже давно.
13 дек 19, 20:12    [22040210]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
KreatorXXI
Member

Откуда: Москва
Сообщений: 1010
Старый плюшевый мишка
KreatorXXI
Симонов Денис,

ну да, понял. Как вариант насоздавать триггеров для разных полей, по одному полю. Так подходит, я считаю.


Ндя. А один триггер для IZM-ов - это, разумеется, пошлость. Немолодёжно. И для всего остального тоже. Типа - есть событие, запись изменена. Есть возможность создать обработчик этого события и в нём отреагировать на любые изменения. Но это ж "при наличии программиста", как рядушком сказано. А вот понажмакивать галки на полях, чтобы Хвастунов понасоздавал триггеров-обработчиков, и не вникать чем они там занимаются и в какой очерёдности, и мешают ли друг другу, есть и ладно - це дило. Ну и заодно наплевать, что надо сделать новый движок, который будет реагировать и генерировать события на изменение полей, а не изменение записи, пусть 100 штук на один оператор update, но мне не надо будет копипастить пару строк для упомянутых IZM-ов из триггера в триггер - это ж на нобелевку потянет. А что ресурсов понадобится на порядок больше и замедлится на порядок - да фигня по сравнению с мировой революцией.


Я так понимаю, главное ничего не менять! Зло это. А, если по делу, то есть вещи удобные и нужные. И, наверно, в стандарт не так просто попадают.
16 дек 19, 10:44    [22040922]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
zigorzn
Member

Откуда:
Сообщений: 20
kdv,

Добрый день.
Идет поиск оптимально простого и быстрого перехода на FB 3.0.
Если просто использовать stdout/stdin , то упираемся в размер BUFSIZ (= 4k) и процессы постоянно ждут друг друга.
При использовании pipe получается увеличить это окно до 256Mb - 1.8Tb БД без индексов "переганяется" за 29ч. (а нужно потом еще 6-8 ч на активацию индексов)
16 дек 19, 10:49    [22040924]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
hvlad
Member

Откуда:
Сообщений: 10993
zigorzn
Если просто использовать stdout/stdin , то упираемся в размер BUFSIZ (= 4k)
Откуда это известно ?
И - о какой ОС идёт речь ?
16 дек 19, 11:53    [22040971]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
hvlad
Member

Откуда:
Сообщений: 10993
zigorzn
Идет поиск оптимально простого и быстрого перехода на FB 3.0.
Если просто использовать stdout/stdin , то упираемся в размер BUFSIZ (= 4k) и процессы постоянно ждут друг друга.
При использовании pipe получается увеличить это окно до 256Mb - 1.8Tb БД без индексов "переганяется" за 29ч.
Ну так может проще в gbak увеличить р-р буфера для stdout ?
16 дек 19, 12:14    [22040995]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
zigorzn
Member

Откуда:
Сообщений: 20
hvlad,

CentOS Linux release 7.7.1908 (Core)
Linux version 3.10.0-1062.9.1.el7.x86_64

stdio.h
...
#define BUFSIZ 4096
....

изменить размер не получилось
16 дек 19, 12:33    [22041016]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
Basil A. Sidorov
Member

Откуда:
Сообщений: 10418
zigorzn
Идет поиск оптимально простого и быстрого перехода на FB 3.0.
Если просто использовать stdout/stdin , то упираемся в размер BUFSIZ (= 4k) и процессы постоянно ждут друг друга.
Команды, которыми запускается конвертация можно увидеть?
16 дек 19, 12:55    [22041049]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
zigorzn
Member

Откуда:
Сообщений: 20
Basil A. Sidorov,

создание файла setfifo :
#!/usr/bin/perl
# usage: name-of-open-fifo size-in-bytes
# http://unix.stackexchange.com/a/353761/119298
use strict;
use Fcntl;
my $fifo = shift @ARGV or die "usage: fifo size";
my $size = shift @ARGV or die "usage: fifo size";
open(FD, $fifo) or die "cannot open";
printf "old size %d\n",fcntl(\*FD, Fcntl::F_GETPIPE_SZ, 0);
my $new = fcntl(\*FD, Fcntl::F_SETPIPE_SZ, int($size));
die "failed" if $new<$size;
printf "new size %d\n",$new;

создание потока "fifo":
mkfifo /dev/shm/pipeFB


запускаем:
/opt/fb25/bin/gbak -b -g -user .... -pass ..... -v -Y /db/l25b.txt -ST TDRW  /db/f25.fdb stdout>/dev/shm/pipeFB | /opt/fb30/bin/gbak -c -i -o  -user ... -pass ... -v -Y /db/l30r.txt -ST TDRW stdin</dev/shm/pipeFB /db/f30_no_idx.fdb

после запуска gbak паралельно делаем увеличение размера покота fifo до 256mb (4k*65536)
./setfifo /dev/shm/pipeFB 268435456


Сообщение было отредактировано: 16 дек 19, 13:26
16 дек 19, 13:18    [22041096]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
Basil A. Sidorov
Member

Откуда:
Сообщений: 10418
zigorzn
 /opt/fb25/bin/gbak -b -g -user ... -pass ... -v -Y /db/l25b.txt -ST TDRW  /db/f25.fdb stdout>/dev/shm/pipeFB | \
/opt/fb30/bin/gbak -c -i -o -user ... -pass ... -v -Y /db/l30r.txt -ST TDRW stdin</dev/shm/pipeFB /db/f30_no_idx.fdb
Насколько медленнее простое:
 /opt/firebird/bin/gbak -b ... база-fb25 stdout | \
/opt/fb30/bin/gbak -c ... stdin база-fb30
?

Насколько быстрее контрольное:
 /opt/firebird/bin/gbak -b ... база-fb25 stdout > /dev/nul
?

P.S.
IMHO, подобные вещи лучше проделывать, предварительно сменив пользователя на firebird (sudo su -s оболочка firebird).
И, насколько я понимаю каналы, должно быть:
 /opt/fb30/bin/gbak -c ... stdin база-fb30 < /dev/shm/pipeFB & ; \
/opt/firebird/bin/gbak -b ... база-fb25 stdout > /dev/shm/pipeFB


Сообщение было отредактировано: 16 дек 19, 13:47
16 дек 19, 13:39    [22041127]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 50808

zigorzn
Идет поиск оптимально простого и быстрого перехода на FB 3.0.

Зря вы это. В переходе между версиями есть грабли, которые делают "простой и быстрый"
переход опасным. Ну, перегоните вы базу, а потом приложение откажется с ней работать и
что? Начнёте искать "простой и быстрый" переход обратно? А его нет.

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

Posted via ActualForum NNTP Server 1.5

16 дек 19, 13:52    [22041157]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 29015
Dimitry Sibiryakov
как заставить старый и новый сервера работать в параллель лично я не знаю.

Еманов об этом говорит постоянно - основной сервер 2.5, и реплика с 3.0.
На 2.5 всё работает, а в реплику 3.0 можно прямо на реальных данных потыкивать чем угодно.
16 дек 19, 14:11    [22041195]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 50808

kdv
Еманов об этом говорит постоянно - основной сервер 2.5, и реплика с 3.0.
На 2.5 всё работает, а в реплику 3.0 можно прямо на реальных данных потыкивать чем угодно.

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

Posted via ActualForum NNTP Server 1.5

16 дек 19, 14:22    [22041212]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
Старый плюшевый мишка
Member

Откуда:
Сообщений: 850
KreatorXXI

Я так понимаю, главное ничего не менять! Зло это. А, если по делу, то есть вещи удобные и нужные. И, наверно, в стандарт не так просто попадают.


Не обижайся. Язык у меня ядовитый, что есть, то есть, каюсь постфактум, но вот токое уж я говно. Я это всё к чему. А к тому, что не надо забывать, что мы с тобой разработчики систем, а не кодеры от забора и до обеда, видящие на вершок дальше своего носа и только один, первый пришедший в голову, вариант решения проблемы или проблемки. И, прежде чем бросаться кодировать, должны обозреть причинно-следственное дерево, произрастающее из планируемого действия и оценить - стоит ли овчинка выделки и не принесёт ли эта выделка, или не имеет ли шанс принести, вселенский геморрой побочными эффектами. Что касается данной конкретной четвёрки полей создатель-время и изменятель-время, есть решение, реализуемое щелчком пальцев и, при современном развитии печатного дела на Западе (С), практически не имеющее побочных эффектов. Оно рвалось с моего языка лет 15 назад, но я свернул эту хотелку в трубочку и засунул себе в задницу. Потому что 3 эффекта остались. Это решение - сделать эту четвёрку неотъемлемым системным атрибутом записей во всех таблицах, включая системные, нет, прямо начиная с них. Со встроенной логикой автоматического заполнения. Отрицательные эффекты:

1. Этого нет в стандарте, следственно, миграция между серверами осложняется.
2. Тогда была эпоха 4-гиговых рейдов и байты приходилось экономить. Пресловутое современное развитие печатного дела множит этот эффект практически на ноль, люди, вона, об использовании блобов в качестве ID задумываются. Но всё равно протесты будут - а мне оно нинада.
3. Есть случаи когда оно действительно нинада. При ручной корректировке данных разработчиком после аварий. Ведь основное целевое назначение четвёрки - выявление хитрожопых или головотяпистых виновных и раздача звездюлей. Вмешательство разработчика может как подпадать под это определение, так и замаскировать преступную деятельность или халатность, если с благими намерениями перекроет сведения о ней. В самописных триггерах вопрос решается на раз, а как быть в системных я не придумал.
16 дек 19, 22:31    [22041645]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
Tonal
Member

Откуда: Новосибирск
Сообщений: 188
От, ещё одна идейка.
В OO API добавить интерфейс для логгирования.
При реализации плагина оно частенько бывает нужно, но так как интерфейса нет каждому плагинописателю приходится городить собственный огород.
22 дек 19, 19:17    [22046381]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 50808

Tonal
В OO API добавить интерфейс для логгирования.

Это боян, я о нём уже годы талдычу.

Posted via ActualForum NNTP Server 1.5

22 дек 19, 19:51    [22046390]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
ёёёёё
Member

Откуда:
Сообщений: 2017
Новогодняя безбашенная идея:
Для энтузиастов доступна версия Firebird 4, она только начала свой путь, поэтому пока только альфа


Предлагаю заменить слово "альфа" на слово "бета".

1883929
31 дек 19, 00:05    [22052037]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
Ivan_Pisarevsky
Member

Откуда: НН
Сообщений: 8597
ёёёёё
Новогодняя безбашенная идея:
Для энтузиастов доступна версия Firebird 4, она только начала свой путь, поэтому пока только альфа


Предлагаю заменить слово "альфа" на слово "бета".

1883929
fixed
31 дек 19, 10:47    [22052131]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
X11
Member

Откуда: Kharkiv, Ukraine
Сообщений: 14302
добавить в EXTRACT новую составляющую даты/времени "LASTDAYOFMONTH", как результат будет 28, 29, 30 или 31.
http://www.ibase.ru/files/firebird/langref25rus/index.html#internalfunc-func-datetime-extract

чтобы вот https://www.sql.ru/forum/1320950/poslednyaya-data-mesyaca
4 янв 20, 21:59    [22053483]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
Симонов Денис
Member

Откуда: Рязань
Сообщений: 10586
X11,

всё это уже есть в 4.0

SELECT
    FIRST_DAY(OF MONTH FROM CURRENT_DATE),
    LAST_DAY(OF MONTH FROM CURRENT_DATE),
    FIRST_DAY(OF YEAR FROM LOCALTIMESTAMP),
    LAST_DAY(OF YEAR FROM LOCALTIMESTAMP),
    FIRST_DAY(OF WEEK FROM DATE '2017-11-01'),
    LAST_DAY(OF WEEK FROM DATE '2017-11-01')
FROM rdb$database;
4 янв 20, 22:17    [22053491]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 50808

Что-то лень мне новую тему начинать, понекрофильствую...

Вроде бы я видел в трекере реквест на флаг NO RESERVE (USE ALL SPACE) для отдельных
таблиц, но сейчас найти не могу. Меня память подводит или поисковые способности?

Posted via ActualForum NNTP Server 1.5

15 янв 20, 19:43    [22060167]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 29015
Dimitry Sibiryakov,

я в 2012 году делал
http://tracker.firebirdsql.org/browse/CORE-3957
но это про опцию гбак. Для каждой таблицы надо no reserve сделать, конечно, давно пора.

CREATE DATABASE ... [NO] RESERVE SPACE
ALTER DATABASE ... SET [NO] RESERVE SPACE
CREATE TABLE ... [[NO] RESERVE SPACE];
ALTER TABLE ... [SET [NO] RESERVE SPACE]
15 янв 20, 21:45    [22060238]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
Старый плюшевый мишка
Member

Откуда:
Сообщений: 850
Dimitry Sibiryakov

Что-то лень мне новую тему начинать, понекрофильствую...

Вроде бы я видел в трекере реквест на флаг NO RESERVE (USE ALL SPACE) для отдельных
таблиц, но сейчас найти не могу. Меня память подводит или поисковые способности?


Если посоревноваться склерозами, то мой мне шепчет про такую опцию на ресторе, но для всей базы. А доку я куда-то задевал, переезжал недавно из одной комнаты в другую.
15 янв 20, 21:46    [22060239]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 50808

kdv
я в 2012 году делал

Да, твоё это я нашёл, но там на пути воплощения лежит подводный камень.

kdv
CREATE TABLE ... [[NO] RESERVE SPACE

Я что-то больше склоняюсь к [USE ALL SPACE | RESERVE SPACE], но это ещё надо будет
перетереть, конечно. Сейчас бы найти отправную точку...

Posted via ActualForum NNTP Server 1.5

15 янв 20, 22:40    [22060266]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
Arioch
Member

Откуда:
Сообщений: 11101
Alexey Kovyazin
Пишите сюда любые, самые безумные идеи


На уровне ODS организовать глобальное хранение строк.
С хэшированием, reference counting, bells and whistles.

На уровне строк в таблицах хранить не тексты - а ссылки на хранилище.

Ну, примерно как MS Excel сохраняет XLSX-файлы.

Сейчас в Firebird два разных текстовых типа.

VARCHAR - ограниченная длина, неэффективное хранение коротких строк внутри длинных столбцов, RLE заменить на что-то более эффективное не удалось.
BLOB - лишние вызовы API и network roundtrips, разнообразные invalid blob id без указания причины

При этом Firebird ещё и запрещает преобразовать одно в другое с объяснением "хрен его знает, что при этом получится".

Глобальное хранилище строк бы
* свело VARCHAR и TEXT BLOB к одному типу данных хотя бы на уровне ODS, для начала
* убрало бы изменение длины записи (row) при изменении длины текстовых данных в записи
* ослабило бы ограничение на изменения длины varchar-столбцов (ввиду предыдущего - не надо заводить новый формат записи)
* при записи идентичных строк в разные записях или таблицах не дублировало бы данные
* позволило придумывать оптимизации хранения, кэширования и чтения-записи различные для структур фиксированного размера (integer, double, pointer/handle) и переменного (строки)
* ускорило бы частичное чтение записей, в которых не все VARCHAR-столбцы присутсвуют в select
* уменьшило бы read disk трафик - сейчас приходится читать весь VARCHAR-столбец(хотя и в RLE). При этом длину столбца выставляют в расчёте на наихудший вариант (строка наибольшей длины), даже если он встречается 1 раз на миллион.

При этом бы
* замедлилась запись строк в таблицу - два cache write вместо одного.
* усложнилась ODS и логика работы с ней
16 янв 20, 14:48    [22060688]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 46 47 48 49 50 51 [52] 53 54 55   вперед  Ctrl
Все форумы / Firebird, InterBase Ответить