Как найти золотник в куче Г...

[valchkou]

Ясно, мне почему-то кажется что те деньги которые вы собираетесь потратить на бл*дей для программистов эффективнее программисту запалтить как зарплату, хотя вы наверное собираетесь совместить в одном флаконе чтобы была и тестерша хорошая и на блядство согласна и главное программистам нравилась.

Идея хорошая но сложно-осуществимая ! Например более правильно это снять офис на одном этаже с модельным агенством или ещё более сники подружить айтишников с короткоюбочными маркетинг промо гёрлс в целях понимания нужд кастамеров! Если у компании правильная атмосфера, бесплатный алкоголь то получается органик блядство высшего качества!

Стенкин, ничего хорошего в етом нет. Послушайте старого заслужанного ветерана. Легкий флирт на работе и теплые дружеские отношения всегда увеличивают производительность.
Но проблема в том, что мало мужиков, которые в состoянии удержаться на уровне легкого флирта. А потом ето начинает мешать работе.

ага размечтались, модели, тестировщицы, б*ди и все это из кармана стенкина.
идея стенкина проста и современна: нанять прыщавых студентов нетрадиционной ориентации.
и получть такой дружный сплоченный, мужской коллектив, почти семья, почти как праздник в диснейленде.
http://www.twobadtourists.com/2016/01/2 ... gay-event/" onclick="window.open(this.href);return false;

ну что, есть еще желающие резюме отослать?

[stenking]

идея стенкина проста и современна: нанять прыщавых студентов нетрадиционной ориентации.

Это мечты или страхи?:)

[mskmel]

Вопрос по сиквелу: зачем писать многостраничные оптимизированные запросы, если на средней величины данных можно просто сгрузить все данные в R или Python и там нормальным человеческим языком слепить отчет с красивыми картинками?

Тут оказывается народ массово SQL освоить не может, а Вы про странности в виде R или Python. Тут порог вхождения сильно выше

Согласен про порог вхождения, но от питона тут собственно лишь прокладка для высасывания данных потребна.

Высасывать то все-равно надо агрегаты, а для этого SQL таки освоить придётся.
Сколько времени и строк кода на Python понадобиться чтобы вот это изобразить? Через 5 лет поняли, что измерений стало несколько ТБ и надо как-то параллельную обработку прикутить. В Oracle это будет сделать минуты 1-3.

Code: Select all

SELECT pnt_id, a_vsi_date vsi_date, a_gl gl_0, 
       a_min_gl min_gl, a_max_gl max_gl, a_avg_gl avg_gl,
       b_gl gl_1, c_gl gl_2, d_gl gl_3
  FROM (SELECT p.pnt_id, v.vsi_date, gl,
               MIN (m.gl) OVER (PARTITION BY p.pnt_id) min_gl,
               MAX (m.gl) OVER (PARTITION BY p.pnt_id) max_gl,
               AVG (m.gl) OVER (PARTITION BY p.pnt_id) avg_gl,
               ROW_NUMBER () OVER (PARTITION BY v.pnt_id ORDER BY v.vsi_date DESC) rn
          FROM patient p, visits v, measures m
         WHERE   p.pnt_id = v.pnt_id
             AND v.pnt_id = m.pnt_id(+) 
             AND v.vsi_id = m.vsi_id(+)
        ) PIVOT (MAX (min_gl) min_gl,
                 MAX (max_gl) max_gl,
                 MAX (avg_gl) avg_gl,
                 MAX (vsi_date) vsi_date,
                 MAX (gl) gl
          FOR rn IN (1 a, 2 b, 3 c, 4 d))

[valchkou]

идея стенкина проста и современна: нанять прыщавых студентов нетрадиционной ориентации.

Это мечты или страхи?:)

это реальность! что кандидатов спугнул ?

[АццкоМото]

Code: Select all

SELECT pnt_id, a_vsi_date vsi_date, a_gl gl_0, 
       a_min_gl min_gl, a_max_gl max_gl, a_avg_gl avg_gl,
       b_gl gl_1, c_gl gl_2, d_gl gl_3
  FROM (SELECT p.pnt_id, v.vsi_date, gl,
               MIN (m.gl) OVER (PARTITION BY p.pnt_id) min_gl,
               MAX (m.gl) OVER (PARTITION BY p.pnt_id) max_gl,
               AVG (m.gl) OVER (PARTITION BY p.pnt_id) avg_gl,
               ROW_NUMBER () OVER (PARTITION BY v.pnt_id ORDER BY v.vsi_date DESC) rn
          FROM patient p, visits v, measures m
         WHERE   p.pnt_id = v.pnt_id
             AND v.pnt_id = m.pnt_id(+) 
             AND v.vsi_id = m.vsi_id(+)
        ) PIVOT (MAX (min_gl) min_gl,
                 MAX (max_gl) max_gl,
                 MAX (avg_gl) avg_gl,
                 MAX (vsi_date) vsi_date,
                 MAX (gl) gl
          FOR rn IN (1 a, 2 b, 3 c, 4 d))

Чуть не сблеванул

[Easbayguy]

У меня сейчас более веселая задачка на следующую неделю. Есть примерно 90 миллиардов записей со 100 байтным ключем, где то 10% дупликатов в 6 базах. И надо сгенерить спискок уникальных записей.

[Kolbasoff]

У меня сейчас более веселая задачка на следующую неделю. Есть примерно 90 миллиардов записей со 100 байтным ключем, где то 10% дупликатов в 6 базах. И надо сгенерить спискок уникальных записей.

1. Создать табличку CREATE TABLE UNIQUE_KEYS ( KEY CHAR(100) CONSTRAINT PRIMARY INDEX, DB_INDEX INT)
2. FOR ( INT i=0, i<LIST_OF_DBS.SIZE, i++ ) { INSERT DB.KEY, i INTO UNIQUE_KEYS }
3. Дупликаты не пройдут
4. В итоге в UNIQUE_KEYS список KEY,DB_INDEX уникальных записей.

Размер таблички ~10 Тб. У вас ведь этих терабайтов хоть залейся.

ПС. На работу удаленным генератором кульных идей берете?

[nyekimov]

Ясно, мне почему-то кажется что те деньги которые вы собираетесь потратить на бл*дей для программистов эффективнее программисту запалтить как зарплату, хотя вы наверное собираетесь совместить в одном флаконе чтобы была и тестерша хорошая и на блядство согласна и главное программистам нравилась.

Идея хорошая но сложно-осуществимая ! Например более правильно это снять офис на одном этаже с модельным агенством или ещё более сники подружить айтишников с короткоюбочными маркетинг промо гёрлс в целях понимания нужд кастамеров! Если у компании правильная атмосфера, бесплатный алкоголь то получается органик блядство высшего качества!

Стенкин, ничего хорошего в етом нет. Послушайте старого заслужанного ветерана. Легкий флирт на работе и теплые дружеские отношения всегда увеличивают производительность.
Но проблема в том, что мало мужиков, которые в состoянии удержаться на уровне легкого флирта. А потом ето начинает мешать работе.

ага размечтались, модели, тестировщицы, б*ди и все это из кармана стенкина.
идея стенкина проста и современна: нанять прыщавых студентов нетрадиционной ориентации.
и получть такой дружный сплоченный, мужской коллектив, почти семья, почти как праздник в диснейленде.
http://www.twobadtourists.com/2016/01/2 ... gay-event/" onclick="window.open(this.href);return false;

ну что, есть еще желающие резюме отослать?

Стесняюсь спросить, откуда о таких событиях ведаешь? Я вот как то ни слухом ни духом. Если я не пингвин, то меня не интересует погода на Антарктике.

[valchkou]

Ясно, мне почему-то кажется что те деньги которые вы собираетесь потратить на бл*дей для программистов эффективнее программисту запалтить как зарплату, хотя вы наверное собираетесь совместить в одном флаконе чтобы была и тестерша хорошая и на блядство согласна и главное программистам нравилась.

Идея хорошая но сложно-осуществимая ! Например более правильно это снять офис на одном этаже с модельным агенством или ещё более сники подружить айтишников с короткоюбочными маркетинг промо гёрлс в целях понимания нужд кастамеров! Если у компании правильная атмосфера, бесплатный алкоголь то получается органик блядство высшего качества!

Стенкин, ничего хорошего в етом нет. Послушайте старого заслужанного ветерана. Легкий флирт на работе и теплые дружеские отношения всегда увеличивают производительность.
Но проблема в том, что мало мужиков, которые в состoянии удержаться на уровне легкого флирта. А потом ето начинает мешать работе.

ага размечтались, модели, тестировщицы, б*ди и все это из кармана стенкина.
идея стенкина проста и современна: нанять прыщавых студентов нетрадиционной ориентации.
и получть такой дружный сплоченный, мужской коллектив, почти семья, почти как праздник в диснейленде.
http://www.twobadtourists.com/2016/01/2 ... gay-event/" onclick="window.open(this.href);return false;

ну что, есть еще желающие резюме отослать?

Стесняюсь спросить, откуда о таких событиях ведаешь? Я вот как то ни слухом ни духом. Если я не пингвин, то меня не интересует погода на Антарктике.

очень просто, когда твои дети подрастут и ты решишь их куда нибудь сводить, то неожиданно можешь узнать много интересного
вот еще пожалуйста, в чикаго каждый год http://chicagonakedride.org/" onclick="window.open(this.href);return false;
кстати тоже хорошая идея для офиса стенкина, так сказать бенефит дополнительный

[NYgal]

Задача нечетко сформулирована:
1.вы хотите сздать новый ключ и привязать легаси ключи к нему?
2. Это полные дупликаты, то есть есть 10% совершенно идентичных записей, включая ключ в разных базах?
3. Если да, то все равно: есть ли предпочтения, из какой базы брать? Может, там хотябы таймстамп разный.

Если все три да, то
Select myseq.nextval, filtrd_dupl.*
From ( --- здесь можно профильтровать
аналитическими функциями предпочтения
Select
from
( select ...
row_number() over ( partition old_key order by pick_priority ) as prty
from
( select src1.* , 1 as pick_priority
from src1
union
....
)
) where prty=1
) filtrd_dupl

Если дурликаты полные и выбирать не надо, то простой union уберет все дупликаты

[NYgal]

Ох, предвижу, накидают тут стенкину идей

[stenking]

Ох, предвижу, накидают тут стенкину идей

Вот и мне интересно как алкоголь и девочки с маркетинг департмента успели превратится в голых геев на велосипедах Вроде пить ещё не начали...

[Albert_al]

У меня сейчас более веселая задачка на следующую неделю. Есть примерно 90 миллиардов записей со 100 байтным ключем, где то 10% дупликатов в 6 базах. И надо сгенерить спискок уникальных записей.

Мне кажется самый быстрый путь будет с созданием pk и exception table

[fruit6]

а индусы бы сделали dblinks & views!
без шуток

[Easbayguy]

Народ, я неточно выразился, не уникальных записей, а ключей. Каждый ключ это ссылка на крупный обьект, который можно вытащить из хранилища. Интересно, как такие задачи решают сторонники Big Data.

[Easbayguy]

Задача нечетко сформулирована:
1.вы хотите сздать новый ключ и привязать легаси ключи к нему?
2. Это полные дупликаты, то есть есть 10% совершенно идентичных записей, включая ключ в разных базах?
3. Если да, то все равно: есть ли предпочтения, из какой базы брать? Может, там хотябы таймстамп разный.

Если все три да, то
Select myseq.nextval, filtrd_dupl.*
From ( --- здесь можно профильтровать
аналитическими функциями предпочтения
Select
from
( select ...
row_number() over ( partition old_key order by pick_priority ) as prty
from
( select src1.* , 1 as pick_priority
from src1
union
....
)
) where prty=1
) filtrd_dupl

Если дурликаты полные и выбирать не надо, то простой union уберет все дупликаты

Простой union на ключи по database links, так как данные в 6 базах (на самом делете шардов больше, но физически 6 баз).
select location from Table1
union
select location from Table1@dblink1
union
....
select location from Table1@dblink5

Это ваш подход?

[Uzito]

Это ваш подход?

Никогда не имел опыта работы с такими объемами, но думаю база загнётся делать union такой. Этож надо проверять уникальность и сортировать имеющиеся ключи каждый раз.

Можно наверное создать табличку для хранения ключей и делать merge using (select key from table@link1) и повторить n раз.
будет медленно и печально, однако.

[NYgal]

а индусы бы сделали dblinks & views!
без шуток

Надеюсь, что materialized , чтобы хотя бы проиндексить, на составные сервера надежды мало, и дурликацию все равно фильтровать надо

[NYgal]

Задача нечетко сформулирована:
1.вы хотите сздать новый ключ и привязать легаси ключи к нему?
2. Это полные дупликаты, то есть есть 10% совершенно идентичных записей, включая ключ в разных базах?
3. Если да, то все равно: есть ли предпочтения, из какой базы брать? Может, там хотябы таймстамп разный.

Если все три да, то
Select myseq.nextval, filtrd_dupl.*
From ( --- здесь можно профильтровать
аналитическими функциями предпочтения
Select
from
( select ...
row_number() over ( partition old_key order by pick_priority ) as prty
from
( select src1.* , 1 as pick_priority
from src1
union
....
)
) where prty=1
) filtrd_dupl

Если дурликаты полные и выбирать не надо, то простой union уберет все дупликаты

Простой union на ключи по database links, так как данные в 6 базах (на самом делете шардов больше, но физически 6 баз).
select location from Table1
union
select location from Table1@dblink1
union
....
select location from Table1@dblink5

Это ваш подход?

Да, только по ключам будет работать быстрее, так как будет тянуть из индексов, а не из таблиц. Просто в лоб union, если не нужно других заморочек. И свежая статистика, если можно, конечно, в сорсах. Всякие мапредьюсы такую простую операцию, естественно, сделают быстрее. Но на немного, думаю. Если просто тянуть индексы

[NYgal]

Это ваш подход?

Никогда не имел опыта работы с такими объемами, но думаю база загнётся делать union такой. Этож надо проверять уникальность и сортировать имеющиеся ключи каждый раз.

Можно наверное создать табличку для хранения ключей и делать merge using (select key from table@link1) и повторить n раз.
будет медленно и печально, однако.

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

[Easbayguy]

Это ваш подход?

Никогда не имел опыта работы с такими объемами, но думаю база загнётся делать union такой. Этож надо проверять уникальность и сортировать имеющиеся ключи каждый раз.

Можно наверное создать табличку для хранения ключей и делать merge using (select key from table@link1) и повторить n раз.
будет медленно и печально, однако.

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

хорошо быть девелопером, никакой разницы сортировать 1,000,000 или 1,000,000,000 или 100,000,000,000

[NYgal]

Это ваш подход?

Никогда не имел опыта работы с такими объемами, но думаю база загнётся делать union такой. Этож надо проверять уникальность и сортировать имеющиеся ключи каждый раз.

Можно наверное создать табличку для хранения ключей и делать merge using (select key from table@link1) и повторить n раз.
будет медленно и печально, однако.

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

хорошо быть девелопером, никакой разницы сортировать 1,000,000 или 1,000,000,000 или 100,000,000,000

Я совсем не девелопер
С сотнями миллионов записей такое у меня работало, зависит от физических характеристик базы, но я предполагаю, что все параметры в базе, принимающей миллиарды записей, и так отполированы, как и разпараллеливание.
Кстати, я как-то сравнивала на десятке миллионов записей merge и update ( сцрипт делала, чтобы починит DQ issue):
еффективность merge терялась на <20% обрабатываемых записей, я поспорила на щелбаны с ДБА, он проспорил.

[ALV00]

Народ, я неточно выразился, не уникальных записей, а ключей. Каждый ключ это ссылка на крупный обьект, который можно вытащить из хранилища. Интересно, как такие задачи решают сторонники Big Data.

Запустить шесть процессов на шести серверах. Каждый будет обрабатывать только локальные данные. Одна сводная таблица на одном из серверов будет содержать уникальные ключи. Каждый процесс проверяет уникальность ключа, делая селект на других серверах. Если ключ уникален, добавлять его в сводную таблицу. Конечно, нужны будут линки между серверами, как индусы предлагают.
PS: да, еще при старте каждого процесса доставать из сводной таблице последний ключ, записанный для данного сервера. На тот случай если процесс прервался, чтобы не начинать сначала

[АццкоМото]

а индусы бы сделали dblinks & views!
без шуток

Надеюсь, что materialized , чтобы хотя бы проиндексить, на составные сервера надежды мало, и дурликацию все равно фильтровать надо

Уверяю вас, дурликацию индусы прошли еще в родном ауле, в нежном возрасте

[NYgal]

а индусы бы сделали dblinks & views!
без шуток

Надеюсь, что materialized , чтобы хотя бы проиндексить, на составные сервера надежды мало, и дурликацию все равно фильтровать надо

Уверяю вас, дурликацию индусы прошли еще в родном ауле, в нежном возрасте

Опечатка, а сколько удовольствия для публики