Category: компьютеры

Category was added automatically. Read all entries about "компьютеры".

trekking, Himalaya

Неопубликованное интервью журналу "Мир ПК" про Астронет

В 2005 году к создателям сайта Astronet.ru обратился журнал "Мир ПК" с идеей рассказать про создание сайта, планы. Я, Миша Прохоров ответили на вопросы, а Женя Родичев стормозил, потом мы все были очень занятые и печать не состоялась. Я раскопал архив на нашем SUN и нашел вот это интервью:

Collapse )
trekking, Himalaya

IOE гоу хоум.

В Китае мне сказали про лозунг IOE нах, который означает освобождение от IBM, Oracle, EMC. Пытаюсь заснуть в двух шагах от Али-Бабы, никак не получается, организм запутался в часовых зонах.Ситуация с импортозамещением в субд здесь такая - денежный фактор здесь совсем не работает, ибо никто здесь за Оракл не платит, даже крупные компании, разве что международным приходится. Здесь важна функциональность на первом месте и сво китайское, на втором. Опенсорс здесь любят, но в одну сторону, все качают себе, потом форкают миллион раз и никому ничего не показывают. На наш мультимастер облизываются, все спрашивают, на гитхабе у нас все выложено ? Радует, что наша квалификация здесь не обсуждается, компанию знают. Постгрес потихоньку начинает наступление на мускуль, который здесь везде. Уже в Али-Бабе создан отдел постгреса, сейчас там в облаке предлагается EDB-шная версия. Завтра-послезавтра буду общаться с бабашниками, может удастся посмотреть на местные достопримечательности. Пока что удалось только в местном статусе старбаксе взять что-то несъедобное американское, ибо добрался до Ханчжоу только к 10 вечера. Вот так, вылетел из Сан Франциско в 15:00 прошлого дня, летел над Тихим океаном, потом на мастер убере пару часов ехал из Шанхая. В Шанхае стоял туман-смог, водитель сказал, что здесь так всегда, жить невозможно. В Ханчжоу получше, но влажность и туман. Гостиница совсем новая, интернет медленный, все заблокировано,но жж пашет и очень даже быстро. Пробовал яндекс почту, работает, но удивительно неудобный интерфейс после Гугла раздражает. Неужели в Яндексе нет спецов по юзабилити? Я с удовольствием перешел бы в Яндекс из Гугла, держит только юзабилити.

Утром будет специальная сессия по гринпламу, аж до обеда. У меня доклад в воскресенье, макбук вроде бы ожил, клавиатура разблокировалась, поэтому сумел сваять доклад. Достала меня эта клавиатура, после просыпания она не всегда работает, иногда требуется несколько минут, а в последний раз потребовалась ночь, хорошо что уже после того, как мы выступили на PG Vsion.

Случайно попалась статья в роеме, про то, как мы не знаем, что нас хочет купить Хуавей и даже делалась оценка. Интересно, кому нужен такой вброс ? Я как раз в Китае в Али Бабе, может действительно, подойти к Джек Ма :) На самом деле, пробраться с нему весьма трудно, надо еще подумать, что такое сказать ему за пять минут, чтобы заинтересовать.


Запись сделана с помощью m.livejournal.com.

trekking, Himalaya

spgist vs gist

Прогнал тесты сегодня на 9.2dev и сравнил результаты gist vs spgist. Данные сгенерены так:
select p.x, p.y into points  from 
( select  (0.5-random())*180 as x, random()*360 as y 
       from ( select generate_series(1,$NROWS) ) as t ) as p;


Краткий вывод такой, что spgist заметно быстрее gist до кол-ва записей 10млн, несмотря на бОльшее количество прочитанных блоков (в spgist процессору надо сильно меньше работать, чем для gist). Остается непонятной, почему spgist так не любит упорядоченные данные - кол-во блоков просто гигантское ! Для 15 млн записей spgist уже начинает проигрывать и связано это с каким-то аномальным количеством прочитанных блоков.

Разницy в количестве найденных записей Саша Коротков объяснил, надеюсь он поправит это. Дело в том, что в spgist происходит тупое сравнение координат, а в gist даже для листьев вызывается функция box_contained, которая сравнивает боксы с точностью до 10^-6, что и вызывает небольшое расхождение.

Время создания индексов gist и spgist не сильно отличается, так как gist значительно ускорился благодаря работе Саши Короткова. На прошлом pgcon в Канаде я показывал, что разница в скорости построения индекса достигала 2-3 раз в пользу spgist.

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

test=# select testname, nrows, (endtime-begintime) as runtime, blks_accessed, totalrowsmatched from results order by nrows,testname;
         testname          |  nrows   |     runtime     | blks_accessed | totalrowsmatched 
---------------------------+----------+-----------------+---------------+------------------
 points ordered buffered   |    10000 | 00:00:00.128679 |        137324 |            40000
 points ordered spgist     |    10000 | 00:00:00.077355 |        229459 |            40000
 points unordered buffered |    10000 | 00:00:00.104902 |        136363 |            40000
 points unordered spgist   |    10000 | 00:00:00.078142 |        215500 |            40000
 points ordered buffered   |  1000000 | 00:00:24.090863 |        359825 |          4000004
 points ordered spgist     |  1000000 | 00:00:06.218287 |       4461765 |          4000000
 points unordered buffered |  1000000 | 00:00:07.345433 |        341337 |          4000004
 points unordered spgist   |  1000000 | 00:00:05.962986 |        693722 |          4000000
 points ordered buffered   | 10000000 | 00:03:32.921534 |       1082246 |         40000062
 points ordered spgist     | 10000000 | 00:01:32.837746 |      38326778 |         40000000
 points unordered buffered | 10000000 | 00:02:27.810558 |        981158 |         40000062
 points unordered spgist   | 10000000 | 00:01:23.498076 |       2195123 |         40000000
 points ordered buffered   | 15000000 | 00:05:14.415563 |       1386540 |         60000098
 points ordered spgist     | 15000000 | 00:05:54.343944 |      58132360 |         59999998
 points unordered buffered | 15000000 | 00:03:43.682043 |       1239613 |         60000098
 points unordered spgist   | 15000000 | 00:04:34.943515 |       2692225 |         60000000
trekking, Himalaya

Компрессия сырых данных (или их потеря)

Сенсоры LHC регистрируют столкновения, которые записываются на хранители. Поток такой, что требуется записывать 1 петабайт каждую секунду, что пока практически невозможно. Решение достигнуто ценою выбрасывания неинтересных столкновений, скажем, столкновения уже известных частиц "никому не интересны". Это позволило снизить поток информации до 1 гигабайта в секунду (ссылка 1, ссылка 2, ссылка 3). Фильтрацию в онлайне осуществляют 2000 процессоров.

Таким образом, вполне может оказаться, что фильтрация реализована с ошибкой и наука пропустила много невоспроизводимых данных. В астрономии, такое невозможно по определению - каждое наблюдение имеют ценность для человечества и не может быть выкинуто даже ради сжатия данных. С другой стороны, планирующийся проект нашего института "Лира" предполагает аналогичную компрессию, а именно, в онлайне определяются границы областей вокруг точечных и протяженных объектов, которые собственно и спасаются, а все остальное уничтожается (считаются различные агрегаты перед уничтожением). Миша Прохоров сказал мне, что таким образом достигается компрессия чуть ли не в 100 раз, т.е. на передать на Землю потребуется в 100 раз меньще DVD.