Прочитал обоснование. Ну что сказать... Есть такая поговорка - "думай меньше - умнее будешь". Лучше бы добавили возможность все эти пои с достопримечательностями убрать, мне (да и далеко не только мне) совершенно неинтересна шашычная "у ашота" и прочее. Можно даже за дополнительные деньги. И да, верните нормальный желтый цвет. Я даже готов и за это доплатить.
Вы знаете, разметка на дорогах и в режиме навигатора выглядит предельно странно - зачем мне пялиться в карты, если я ее могу наблюдать непосредственно? Кроме того, в навителе уже много-много лет есть простая и удобная фича - "следующий маневр". Яндекс все никак не дозреет.
Что-то выглядит сложно и медленно. Так-то если по уму - находим в телеметрии случаи превышения и соединяем их с машинами. Оно и в лоб будет неплохо работать, а если чуть постараться - вообще моментально.
select from car c where c.id in(select c_id from telemetry t where t.telemetry_created_at_dttm>now()-make_interval(weeks:=3) and t.speed>140)
В каршеринге яндекса 17 тыс. машин; при пятиминутных интервалах за три недели - около 5 млн строк, ни о чем.
Какая-то антиреклама, "все должно делаться медленно и неправильно"
Если налететь на помехи от военных все будет не так хорошо. Не знаю, умеют ли они сдвигать время в будущее, но в прошлое минут на 5-20 - запросто.
Собственно, я так в машине определяю, будет навигатор работать или точно нет - если на панели часы расходятся с часами на экране - стало быть, помехи, навигатор бесполезен.
"...потоков трафика и веб-активности, веб-аналитики, анализа данных, структурированных логов и данных о событиях." А зачем тут, извините, любая СУБД общего назначения, что постгрес, что оракл, что сайбейз, что еще кто? В ней прорва усилий тратится на обеспечение корректного параллельного доступа к данным для их модификации, чего для примеров не требуется - это просто неизменяемые логи.
"Недавно она помогла нам найти 13 битых страниц в 20-терабайтной БД всего за 40 минут, при том что была развернута на весьма нестабильно работающей дисковой системе одного из наших клиентов." "Курить я буду, но пить не брошу" Может быть, не стоило и связываться с "весьма нестабильно работающей дисковой системой"?
Я так понимаю, вы столь юны, что вам паспорт еще не меняли, иначе бы вы увидели там раздел "сведения о ранее выданных паспортах" :-) Завидую. Честно :-) А вот у меня там все вплоть до советского. Но это вторичный вопрос; на самом деле если там хранить изменяемые данные, то невозможно точно ответить на простой вопрос - "кто именно подавал заявления на такую-то дату?"
"Тезис второй: Естественный ключ всегда будет меняться." Разумеется нет. Вот, предположим, пришел некий Пупкин Василий Насильевич ставить машину с вином таким-то на учет, о чем и занесли факт в таблицу "заявления о постановке на учет" - дата-время, фио, паспортные данные, вин, что-то еще.
Все, теперь делай что хочешь, но прошлое у греков не могли изменить даже боги, чего уж тут говорить о разработчиках.
Более того, изменения этих данных в принципе не должно быть, это уже предпосылка мошенничества.
Паспортные данные, время и вин в данном случае - отличный неизменный естественный ключ (я от него брал бы хеш, так удобнее и короче, но в общем разница непринципиальная).
Вы правы, искусственный ключ по сути утверждение - "а вот это мы будем называть гнвоерк" и не более. Соответственно, в некоторой базе с искусственным ключом один Иван Иваныч запросто может явиться во множестве ипостасей, как индийские боги, и искусственные ключи просто позволяют скрыть эту проблему, причем в первую очередь от разработчика. По-хорошему, как мне кажется, надо иметь а)искусственный ключ, причем желательно не int, а что-то типа UUID или подобного б)уникальный естественный ключ (или что-то более замысловатое)
"Общепринятое правило — устанавливать shared_buffers на уровне 25% от доступной оперативной памяти сервера. Например, для сервера с 32 ГБ RAM, значение будет таким:
По факту btree быстрее, умеет уникальность и больше-меньше. hash хорошо только в случае большого списка колонок, там размер значения хеша фиксированный.
Не очень понимаю, как вы собираетесь обеспечивать "ограничения бизнес-логики" без базы: есть два (или три, или тридцать три) сервера, реализующих "апи", в итоге они могут понаделать сколько угодно невалидных купонов.
Прочитал обоснование.
Ну что сказать... Есть такая поговорка - "думай меньше - умнее будешь".
Лучше бы добавили возможность все эти пои с достопримечательностями убрать, мне (да и далеко не только мне) совершенно неинтересна шашычная "у ашота" и прочее. Можно даже за дополнительные деньги.
И да, верните нормальный желтый цвет. Я даже готов и за это доплатить.
Вы знаете, разметка на дорогах и в режиме навигатора выглядит предельно странно - зачем мне пялиться в карты, если я ее могу наблюдать непосредственно?
Кроме того, в навителе уже много-много лет есть простая и удобная фича - "следующий маневр". Яндекс все никак не дозреет.
Что-то выглядит сложно и медленно.
Так-то если по уму - находим в телеметрии случаи превышения и соединяем их с машинами. Оно и в лоб будет неплохо работать, а если чуть постараться - вообще моментально.
select from car c where c.id in(select c_id from telemetry t where t.telemetry_created_at_dttm>now()-make_interval(weeks:=3) and t.speed>140)
В каршеринге яндекса 17 тыс. машин; при пятиминутных интервалах за три недели - около 5 млн строк, ни о чем.
Какая-то антиреклама, "все должно делаться медленно и неправильно"
Да, где-то тут self join совершенно непонятно.
Какая же вы молодец!
Возьмите питон. Там есть все это плюс прорва другого плюс сразу плюс штатно.
Если налететь на помехи от военных все будет не так хорошо. Не знаю, умеют ли они сдвигать время в будущее, но в прошлое минут на 5-20 - запросто.
Собственно, я так в машине определяю, будет навигатор работать или точно нет - если на панели часы расходятся с часами на экране - стало быть, помехи, навигатор бесполезен.
"...потоков трафика и веб-активности, веб-аналитики, анализа данных, структурированных логов и данных о событиях."
А зачем тут, извините, любая СУБД общего назначения, что постгрес, что оракл, что сайбейз, что еще кто? В ней прорва усилий тратится на обеспечение корректного параллельного доступа к данным для их модификации, чего для примеров не требуется - это просто неизменяемые логи.
"Недавно она помогла нам найти 13 битых страниц в 20-терабайтной БД всего за 40 минут, при том что была развернута на весьма нестабильно работающей дисковой системе одного из наших клиентов."
"Курить я буду, но пить не брошу"
Может быть, не стоило и связываться с "весьма нестабильно работающей дисковой системой"?
Так это философия и есть в чистом виде, см. Аристотель, "Категории". Вот прям с первых строк.
Я так понимаю, вы столь юны, что вам паспорт еще не меняли, иначе бы вы увидели там раздел "сведения о ранее выданных паспортах" :-)
Завидую. Честно :-)
А вот у меня там все вплоть до советского.
Но это вторичный вопрос; на самом деле если там хранить изменяемые данные, то невозможно точно ответить на простой вопрос - "кто именно подавал заявления на такую-то дату?"
И что? Он с новым паспортом окажется в прошлом?
"Тезис второй: Естественный ключ всегда будет меняться."
Разумеется нет. Вот, предположим, пришел некий Пупкин Василий Насильевич ставить машину с вином таким-то на учет, о чем и занесли факт в таблицу "заявления о постановке на учет" - дата-время, фио, паспортные данные, вин, что-то еще.
Все, теперь делай что хочешь, но прошлое у греков не могли изменить даже боги, чего уж тут говорить о разработчиках.
Более того, изменения этих данных в принципе не должно быть, это уже предпосылка мошенничества.
Паспортные данные, время и вин в данном случае - отличный неизменный естественный ключ (я от него брал бы хеш, так удобнее и короче, но в общем разница непринципиальная).
Вы правы, искусственный ключ по сути утверждение - "а вот это мы будем называть гнвоерк" и не более.
Соответственно, в некоторой базе с искусственным ключом один Иван Иваныч запросто может явиться во множестве ипостасей, как индийские боги, и искусственные ключи просто позволяют скрыть эту проблему, причем в первую очередь от разработчика.
По-хорошему, как мне кажется, надо иметь а)искусственный ключ, причем желательно не int, а что-то типа UUID или подобного б)уникальный естественный ключ (или что-то более замысловатое)
Кто бы мог подумать.
"Общепринятое правило — устанавливать
shared_buffersна уровне 25% от доступной оперативной памяти сервера. Например, для сервера с 32 ГБ RAM, значение будет таким:Нет
По факту btree быстрее, умеет уникальность и больше-меньше.
hash хорошо только в случае большого списка колонок, там размер значения хеша фиксированный.
Проще было документацию по pgcrypto процитировать.
Не очень понимаю, как вы собираетесь обеспечивать "ограничения бизнес-логики" без базы: есть два (или три, или тридцать три) сервера, реализующих "апи", в итоге они могут понаделать сколько угодно невалидных купонов.
Триггер некорректный - при параллельной вставке можно пропустить два купона.
Причем тут ПВО и авиация? Кто-то там удивлялся, как такое в наше время может быть. Да легко может быть.