Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Firebird, InterBase Новый топик    Ответить
Топик располагается на нескольких страницах: ←Ctrl  назад   1 .. 28 29 30 31 32 [33] 34 35 36 37 .. 55   вперед  Ctrl→
 Re: Конкурс идей про Firebird  [new]
Basil A. Sidorov
Member

Откуда:
Сообщений: 10897
 		...
- Ну что - помогло?
- Нет, батюшка - все куры подохли.
- Жаль. У меня ещё столько идей было ...
20 мар 19, 14:59    [21838579]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
sysdba22
Member

Откуда:
Сообщений: 259
 		Идея для ФБ 5 номер один -- распараллеливание. А то тяжко клиенту, который ставит на сервер 4 процессора по 24 ядра каждый объяснять почему время выполнения запроса осталось тем же. Тем более что конкуренты уже практически все используют параллельные вычисления.

Сортировка прекрасно бьется на куски, сортируется по-отдельности и потом сливается. Сложный запрос -- можно себе представить как JOINы попарно одновременно выполняются на разных процессорах, а результат затем объединяется.

Без этого, увы, все большие клиенты, которых через Делфи угораздило оказаться на ФБ, свалят в течение ближайших 5-10 лет.

На втором месте память, которая сейчас не проблема. Надо 512 Гб -- поставим 512. Надо 1 Тб -- будет 1 ТБ. Соответственно, и алгоритмы можно подтягивать под новые реалии.

Третье место -- SSD. Они теперь повсеместно, а с ними и огромные рандомные IO. Опять-таки, многие алгоритмы из 80-х уже не актуальны при такой технике.
20 мар 19, 18:38    [21838853]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
Ivan_Pisarevsky
Member

Откуда: НН
Сообщений: 8716
sysdba22
Сложный запрос -- можно себе представить как JOINы попарно одновременно выполняются на разных процессорах, а результат затем объединяется.
А я вот как-то с трудом подобное представляю, можно для запасшихся попкорном расписать мысль по-подробней?
sysdba22
Соответственно, и алгоритмы можно подтягивать под новые реалии.
Какие алгоритмы?
Память есть, ССД есть - мне от них отказаться из-за отсталых алгоритмов? Но, блин, понравилось уже.
Имя, сестра, имя! (с)
20 мар 19, 18:50    [21838870]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
sysdba22
Member

Откуда:
Сообщений: 259
 		кто-то с трудом представляет, кто-то уже несколько лет как использует:

https://www.mssqltips.com/sqlservertip/4939/how-to-force-a-parallel-execution-plan-in-sql-server-2016/
20 мар 19, 18:56    [21838876]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
Filippov Dmitry
Member

Откуда: Пенза->Москва
Сообщений: 132
 		sysdba22,

и всё таки, здесь ".. не всё так однозначно" (с)
Например так http://www.queryprocessor.com/how-to-get-a-parallel-plan/

Ну и также погуглив можно найти всякое.
20 мар 19, 19:31    [21838911]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
Дегтярев Евгений
Member

Откуда: Барнаул
Сообщений: 1985
sysdba22
Без этого, увы, все большие клиенты, которых через Делфи угораздило оказаться на ФБ, свалят в течение ближайших 5-10 лет.

ты про себя или про своих клиентов?
если второе - то у тебя достаточно времени чтобы свалить вместе с ними )
20 мар 19, 19:54    [21838927]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
Vlad F
Member

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

Однако, я тоже за все хорошее и против плохого, да.
20 мар 19, 21:17    [21838964]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
fraks
Member

Откуда: Новосибирск
Сообщений: 1631
sysdba22
На втором месте память, которая сейчас не проблема. Надо 512 Гб -- поставим 512. Надо 1 Тб -- будет 1 ТБ. Соответственно, и алгоритмы можно подтягивать под новые реалии.


Э? Предлагается просрать текущую нишу и полезть бодаться с другими в их нишах?
У кого теребайт оперативки не проблема - те работают не на Firebird, как правило.
21 мар 19, 04:05    [21839053]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
sysdba22
Member

Откуда:
Сообщений: 259
 		речь не про размер памяти, как абсолютную величину, а про то что сейчас как правило достаточно памяти, чтобы всю базу, все сортировки и выборки держать сразу в озу.
21 мар 19, 08:58    [21839123]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
Симонов Денис
Member

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

какие-то у вас слишком упрощённые представление о том как оно работает внутри.
21 мар 19, 09:31    [21839162]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
rdb_dev
Member

Откуда: с болот
Сообщений: 3604
Ivan_Pisarevsky
sysdba22
Сложный запрос -- можно себе представить как JOINы попарно одновременно выполняются на разных процессорах, а результат затем объединяется.
А я вот как-то с трудом подобное представляю, можно для запасшихся попкорном расписать мысль по-подробней?
Недавно на форуме была тема, где обсасывали маркетинговые фишки Interbase'а в сравнении с FirebirdSQL. Похоже, что в Interbase перебор (скан) по натуралу распаралелен через OpenMP или что-то похожее, да и по индексу распаралелить скан тоже можно.
21 мар 19, 10:36    [21839241]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
rdb_dev
Member

Откуда: с болот
Сообщений: 3604
sysdba22
Третье место -- SSD. Они теперь повсеместно, а с ними и огромные рандомные IO. Опять-таки, многие алгоритмы из 80-х уже не актуальны при такой технике.
Алгоритмами чтения/записи при использовании разного рода носителей должны заниматься драйверы операционной системы, но никак не сервер управления реляционными базами данных.
21 мар 19, 10:39    [21839243]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
Мимопроходящий
Member

Откуда: бурятский тундрюк, эсквайр
Сообщений: 31963
21.03.2019 10:36, rdb_dev пишет:
> Похоже, что в Interbase перебор (скан) по натуралу распаралелен через OpenMP или что-то похожее, да и по индексу распаралелить скан тоже можно.

строить гипотезы на основании маркетинговых высеров, это хм... готично!

Posted via ActualForum NNTP Server 1.5
21 мар 19, 10:45    [21839253]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
rdb_dev
Member

Откуда: с болот
Сообщений: 3604
sysdba22
речь не про размер памяти, как абсолютную величину, а про то что сейчас как правило достаточно памяти, чтобы всю базу, все сортировки и выборки держать сразу в озу.
То есть открывая БД, FirebirdSQL должен отобразить её через mmap() на ОЗУ? Этого будет достаточно?
21 мар 19, 10:45    [21839254]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
Мимопроходящий
Member

Откуда: бурятский тундрюк, эсквайр
Сообщений: 31963
21.03.2019 10:45, rdb_dev пишет:
> То есть открывая БД, FirebirdSQL должен отобразить её через mmap() на ОЗУ? Этого будет достаточно?

ты не устал жить в "плоской вселенной"?
тебя это не напрягает?
хочешь поговорить об этом?

Posted via ActualForum NNTP Server 1.5
21 мар 19, 10:46    [21839258]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
Симонов Денис
Member

Откуда: Рязань
Сообщений: 10793
rdb_dev
Похоже, что в Interbase перебор (скан) по натуралу распаралелен через OpenMP или что-то похожее, да и по индексу распаралелить скан тоже можно.


ну как можно нести такую чушь? Даже не смешно
21 мар 19, 10:47    [21839263]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
rdb_dev
Member

Откуда: с болот
Сообщений: 3604
Мимопроходящий
21.03.2019 10:36, rdb_dev пишет:
> Похоже, что в Interbase перебор (скан) по натуралу распаралелен через OpenMP или что-то похожее, да и по индексу распаралелить скан тоже можно.

строить гипотезы на основании маркетинговых высеров, это хм... готично!
OpenMP достаточно часто стали использовать для распараллеливания обработки массивов данных и если разработчики Interbase утверждают, что на многопроцессорной системе скан по натуралу у них в несколько раз быстрее при всех прочих равных, то тут вывод, как бы, очевиден - параллельные вычисления.
21 мар 19, 10:48    [21839266]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
WildSery
Member

Откуда: да, оттуда.
Сообщений: 19671
 		rdb_dev,

И ты говори (ц)
21 мар 19, 10:49    [21839271]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
rdb_dev
Member

Откуда: с болот
Сообщений: 3604
Мимопроходящий
21.03.2019 10:45, rdb_dev пишет:
> То есть открывая БД, FirebirdSQL должен отобразить её через mmap() на ОЗУ? Этого будет достаточно?

ты не устал жить в "плоской вселенной"?
тебя это не напрягает?
хочешь поговорить об этом?
Поговорить о том, что существует масса СУБД, которые открывают файлы БД подобным образом и что известная компания "Петер-сервис" в своей реализации БД для LDAP решила использовать именно этот подход из-за его быстродействия, проверив массу других вариантов? Или ты просто никогда не слышал про СУБД с отображением на память?
21 мар 19, 10:51    [21839273]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
rdb_dev
Member

Откуда: с болот
Сообщений: 3604
Симонов Денис
rdb_dev
Похоже, что в Interbase перебор (скан) по натуралу распаралелен через OpenMP или что-то похожее, да и по индексу распаралелить скан тоже можно.
ну как можно нести такую чушь? Даже не смешно
Можешь предложить иное объяснение? Ты, хоть когда-нибудь, пробовал использовать OpenMP?
21 мар 19, 10:53    [21839277]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
Симонов Денис
Member

Откуда: Рязань
Сообщений: 10793
rdb_dev
что на многопроцессорной системе скан по натуралу у них в несколько раз быстрее при всех прочих равных


ты это проверял?
21 мар 19, 10:57    [21839282]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 29547
rdb_dev
Похоже, что в Interbase перебор (скан) по натуралу распаралелен

нет. Более того, если на штатном размере базы tpc, как у них в тесте, вроде бы всё одинаково с FB (со сканом),
то при 30 гиг базе у ИБ скан ужасен, там почему-то ничего не помогает, всё намного хуже чем у ФБ.
Я делал тесты, но результаты получились настолько неоднозначные, что я решил ничего не публиковать.
21 мар 19, 10:59    [21839283]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
rdb_dev
Member

Откуда: с болот
Сообщений: 3604
Симонов Денис
rdb_dev
что на многопроцессорной системе скан по натуралу у них в несколько раз быстрее при всех прочих равных
ты это проверял?
Нет. А ты проверял?
21 мар 19, 11:01    [21839286]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
WildSery
Member

Откуда: да, оттуда.
Сообщений: 19671
rdb_dev
Нет. А ты проверял?
Но утверждаешь же именно ты, на основании фантазий маркетологов :)
21 мар 19, 11:04    [21839295]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
Симонов Денис
Member

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

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

Во-первых ещё не известно откуда чтение идёт с диска, файлового кеша или страничного кеша. В разные моменты времени работы с БД может быть по разному. Какой именно из вариантов был в тесте не ясно.
Во-вторых в Firebird ещё и каждая запись распаковывается это не всегда дешёво.
В-третьих может читаться не только сама запись, а ещё и дельта для восстановления версии.
21 мар 19, 11:10    [21839304]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: ←Ctrl  назад   1 .. 28 29 30 31 32 [33] 34 35 36 37 .. 55   вперед  Ctrl→
Все форумы / Firebird, InterBase Ответить