Как же он избавит, если все данные будут живыми? Мне кажется, вам просто следовало для чистоты эксперимента сделать меньше метаданных и большее количество файлов под этими метаданными, вот и всё.
Ваш подход - "нужно N файлов; давай нагенерим таблиц столько, чтобы метаданные по ним дали N файлов". А есть ещё другой - "нужно N файлов; давай нагенерим разумное число таблиц и сгенерим для них реальные данные, чтобы получилось N файлов". Вы в случае с GP даже не дошли до тестирования как он работает с множеством файлов ДАННЫХ, упёршись в методы работы с каталогом.
Кстати, откуда в случае с SQL движком над HDFS и S3 берутся медатанные и в чём отличие методов работы с ними от GP? Что там происходит при выполнении DDL?
Проблема с распуханием каталога в GP при увеличении количества объектов есть. Но количество файлов можно увеличить не только увеличением количества метаданных, а самими данными. Чтобы в диск не упираться, можно было перекомпилить GP с меньшим размером файлов (<1ГБ) и нагенерить файлов вставкой в таблицы. Тогда бы было честнее. А так - сравнение тёплого с мягким, бессмсленное.
Это бывает сложно. Вот мне, например, необходимо чтобы компилилось быстро, чтобы окна переключались быстро, чтобы приложения открывались быстро. Всё для того, чтобы мысль не ушла далеко. Для меня, например, секунда при переключении окон уже долго. А если работать через какой-нибудь RDP на слабой тачке, когда нажатие клавиши отрабаыватет с задержкой (не знаю точно какой, не замерял, но для обывателя небольшой, типа полсекунды) и всё на хокеях, то хочется всё это дерьмо выкинуть в окно. Вот когда это пытаешься объяснить тому, кто с этим не сталкивался или кому это никогда не было нужно, выглядишь капризным выдумщиком.
Ну упрощать тоже не стоит. Меня, например, как налогоплательщика, очень бесит, когда я прихожу в госконтору и компьютер (как пример) у его сотрудника работает долго. Это просто не удобно и раздражает. А обосновать, почему нужно 16 ГБ или 4 ядра вместо 4ГБ и 2 ядер бывает сложно. Потому что, в принципе, всё должно работать и на 4 ГБ и 2 ядрах, но оно просто неудобно в эксплуатации. Вот от этого "неудобно" обычно просто отмахиваются, говоря что-нибудь типа "зачем тебе это нужно", а когда объясняешь - ответ "не выдумывай" или "ну подожди немного". Не знаю почему, но некоторые субъективные факторы люди принимающие решение просто не хотят учитывать в угоду экономии или ещё чего-то. Может потому что сами с этим не сталкиваются.
В то же время, согласен, что макбук секретарше не нужен наверно, если она не делает ничего того, для чего он требуется. В общем, надо идти от потребностей как-то, а не ровнять всех под одну гребёнку с этими СуньЛао (даже не знаю настоящий ли бренд :-) Нельзя просто отмахиваться от этих потребностей, но в то же время нельзя их завышать.
Ну, если подумать, то алгоритм в виде ФЗ - это управляющая система. А объект управления - это люди, которые производят закупки. Так вот есть такой Закон необходимого разнообразия, который говорит о том, что сложность управляющей системы должна быть не ниже сложности объекта управления. А люда - очень сложная система, поэтому и управлять ими с помощью алгоритмов получится только когда сами алгоритмы превратятся в то, что сейчас называется "искусственный интеллект". Вот так вижу эту проблему.
По разделу "Пример работы алгоритма коррекции ошибок Fuzzy Extractor": не совсем понимаю, почему HelperData не является секретом? Ведь это копия SRAM PUF Response (с точностью до побитовой инверсии). А зная SRAM PUF Response, видимо, можно уже и Digital Fingerprint получить.
with price(stock_id, prod_id, start_date, kind, price1, cost1, bonus1) as (
values (1,1,to_date('2000-01-01','YYYY-MM-DD'),'R',100.0,32.12,6.49),
(1,1,'2000-01-02','P', 80.0, 0, 0),
(1,1,'2000-01-03','P', 70.0, 0, 0),
(1,1,'2000-01-04','R',110.0,33.48,6.19),
(1,1,'2000-01-05','P', 90.0, 0, 0),
(1,1,'2000-01-06','R',120.0,41.22,6.19),
(1,1,'2000-01-07','P', 80.0, 0, 0),
(1,1,'2000-01-08','P', 90.0, 0, 0),
(1,1,'2000-01-09','R', 93.0,36.87,6.49),
(1,1,'2000-01-10','R', 94.0,36.85,6.99),
(1,2,'2000-01-01','R',101.0,52.06,9.00),
(1,2,'2000-01-02','P', 81.0, 0, 0),
(1,2,'2000-01-03','P', 71.0, 0, 0),
(1,3,'2000-01-04','R',111.0,64.96,4.50),
(1,3,'2000-01-05','P', 92.0, 0, 0),
(1,3,'2000-01-06','R',122.0,66.83,4.60),
(1,3,'2000-01-07','P', 82.0, 0, 0),
(1,3,'2000-01-08','P', 92.0, 0, 0)
)
select t.*,
case range_num
when 0
then null
else first_value(price1) over (partition by stock_id, prod_id, range_num order by start_date)
end as pricex
from (select p.*,
sum(case kind
when 'R'
then 1
else 0
end) over (partition by stock_id, prod_id order by start_date) as range_num
from price p) t
order by t.stock_id, t.prod_id, t.start_date;
Как же он избавит, если все данные будут живыми? Мне кажется, вам просто следовало для чистоты эксперимента сделать меньше метаданных и большее количество файлов под этими метаданными, вот и всё.
Ваш подход - "нужно N файлов; давай нагенерим таблиц столько, чтобы метаданные по ним дали N файлов". А есть ещё другой - "нужно N файлов; давай нагенерим разумное число таблиц и сгенерим для них реальные данные, чтобы получилось N файлов". Вы в случае с GP даже не дошли до тестирования как он работает с множеством файлов ДАННЫХ, упёршись в методы работы с каталогом.
Кстати, откуда в случае с SQL движком над HDFS и S3 берутся медатанные и в чём отличие методов работы с ними от GP? Что там происходит при выполнении DDL?
Проблема с распуханием каталога в GP при увеличении количества объектов есть. Но количество файлов можно увеличить не только увеличением количества метаданных, а самими данными. Чтобы в диск не упираться, можно было перекомпилить GP с меньшим размером файлов (<1ГБ) и нагенерить файлов вставкой в таблицы. Тогда бы было честнее. А так - сравнение тёплого с мягким, бессмсленное.
Это бывает сложно. Вот мне, например, необходимо чтобы компилилось быстро, чтобы окна переключались быстро, чтобы приложения открывались быстро. Всё для того, чтобы мысль не ушла далеко. Для меня, например, секунда при переключении окон уже долго. А если работать через какой-нибудь RDP на слабой тачке, когда нажатие клавиши отрабаыватет с задержкой (не знаю точно какой, не замерял, но для обывателя небольшой, типа полсекунды) и всё на хокеях, то хочется всё это дерьмо выкинуть в окно. Вот когда это пытаешься объяснить тому, кто с этим не сталкивался или кому это никогда не было нужно, выглядишь капризным выдумщиком.
Ну упрощать тоже не стоит. Меня, например, как налогоплательщика, очень бесит, когда я прихожу в госконтору и компьютер (как пример) у его сотрудника работает долго. Это просто не удобно и раздражает. А обосновать, почему нужно 16 ГБ или 4 ядра вместо 4ГБ и 2 ядер бывает сложно. Потому что, в принципе, всё должно работать и на 4 ГБ и 2 ядрах, но оно просто неудобно в эксплуатации. Вот от этого "неудобно" обычно просто отмахиваются, говоря что-нибудь типа "зачем тебе это нужно", а когда объясняешь - ответ "не выдумывай" или "ну подожди немного". Не знаю почему, но некоторые субъективные факторы люди принимающие решение просто не хотят учитывать в угоду экономии или ещё чего-то. Может потому что сами с этим не сталкиваются.
В то же время, согласен, что макбук секретарше не нужен наверно, если она не делает ничего того, для чего он требуется. В общем, надо идти от потребностей как-то, а не ровнять всех под одну гребёнку с этими СуньЛао (даже не знаю настоящий ли бренд :-) Нельзя просто отмахиваться от этих потребностей, но в то же время нельзя их завышать.
Ну, если подумать, то алгоритм в виде ФЗ - это управляющая система. А объект управления - это люди, которые производят закупки. Так вот есть такой Закон необходимого разнообразия, который говорит о том, что сложность управляющей системы должна быть не ниже сложности объекта управления. А люда - очень сложная система, поэтому и управлять ими с помощью алгоритмов получится только когда сами алгоритмы превратятся в то, что сейчас называется "искусственный интеллект". Вот так вижу эту проблему.
Почему не умеет? А вот так:
Или это не то, что вы имели в виду?
По разделу "Пример работы алгоритма коррекции ошибок Fuzzy Extractor": не совсем понимаю, почему HelperData не является секретом? Ведь это копия SRAM PUF Response (с точностью до побитовой инверсии). А зная SRAM PUF Response, видимо, можно уже и Digital Fingerprint получить.
А как изменится ситуация когда будет спутниковый интернет, например, Starlink?
Тут в начале индексы местами поменять надо