Да и так сразу видно, как рот откроет. Салтыков-Щедрин, «Органчик». Только технологический прогресс чуть расширил ассортимент «Не потерплю!» и «Разорю!».
По 15-20 минут на самокат? Тут обещают «крупноузловую сборку из 118 узлов и комплектующих», это по десять секунд в среднем на узел. Разве что они каждый отдельный винтик в комплектующие записали. Могли конечно.
Walmart таки технологическая компания. Они были пионерами в data warehouse, в 92ом были первыми в мире с терабайтным data warehouse, гордились управлением цепочками поставок и запасами в реальном времени, предсказанием спроса по погоде и так далее. Но сейчас похоже сдали.
На Rust нельзя описать нормально многие структуры. Нужны либо unsafe, либо проверки в рантайме. Borrow checker ограничен в том, безопасность чего он может доказать. Довольно большой класс безопасных структур он не пропустит, из-за чего в том же Rust много библиотечных классов реализовано на unsafe.
Вы необходимо столкнетесь с чем-то подобным, буду ждать следующих статей как вы это решили.
Тот же full scan нормален на 1 мегабайте, не ОК на допустим 10 Тб. Но где граница, и как сделать так чтобы самый важный запрос не упал, когда самая главная таблица вдруг превысила этот порог на один байт?
Разные No/NewSQL базы тоже стабильные точечные запросы обеспечивают. А вот произвольный SQL не могут, и не видно как это было бы возможно.
В чем-то сходно с Rust, какие-то ограниченные структуры владения объектами можно описать и он гарантирует безопасность. А вот произвольный связи как в плюсах не сделать.
Выбор, и там и там, между универсальностью и гарантиями. В общем для обоих есть применения, но универсальность нужна чаще конечно.
Одно отличие я заметил, в С++ объект освобождается по выходу из области видимости, а тут иногда раньше, по месту "последнего" использования. Это память в каких-то случаях экономит, но редко. Зато ломает RAII паттерн.
Но разница как-то явно не достаточная чтобы избежать нормального borrow checker. А что компилятор делает если этот указатель передается в другие функции из статьи совсем не ясно.
Я бы даже сказал, что возможно стоит это позиционировать как механизм макросов, на уровне AST, может быть интересным, хотя видны и проблемы. Но это не про исключения.
А какой нибудь практический пример использования таких исключений есть? Не очень понятно, что в примере с делением на ноль можно написать внутри if (op == 0), кроме terminate(), а это не совсем то что обычно понимают под обработкой исключений. Ну может быть альтернативно установить какой-нибудь глобальный флаг ошибки, вернуть какую-нибудь ерунду, и продолжить вычисления? Тоже так себе идея. Да и сделать оба варианта можно эффективнее без лишних if через системные исключения.
Есть дата, когда запись появляется в базе (со всеми оговорками, что могут быть разные задержки, но идея понятна). Думаю что здесь это как раз sold_at, если другая - то надо использовать ее. Обычно по этому же полю происходит чистка базы.
И для этого поля PARTITION BY естественное решение, решающее сразу множество проблем. Для остальных полей очевидно индексы.
В некоторых базах данных, кстати, PARTITION BY по дате заказа ускорит запросы и по дате поставки, они сильно коррелируют. Но, увы, это пока не про Postgres.
С ежедневными отчётами, почему борьба за индекс, а не PARTITION BY? Казалось бы, как раз для таких случаев, исключает лишнее сканирование, и решает проблемы с вакуумом и пр.
Ваш выбор стула в целом ясен
Требуют от Телеграмма гораздо больше, чем запретить выдачу.
Он-то не пропадет.
Да и так сразу видно, как рот откроет. Салтыков-Щедрин, «Органчик». Только технологический прогресс чуть расширил ассортимент «Не потерплю!» и «Разорю!».
По 15-20 минут на самокат? Тут обещают «крупноузловую сборку из 118 узлов и комплектующих», это по десять секунд в среднем на узел. Разве что они каждый отдельный винтик в комплектующие записали. Могли конечно.
Я роботов не ожидал, но представил себе простенький конвейер. Похоже однако и его нет.
Судя по фото, полностью ручная сборка, даже какую-нибудь старую китайскую линию по сборке не купили? Или всё же хоть немного автоматизировали?
Walmart таки технологическая компания. Они были пионерами в data warehouse, в 92ом были первыми в мире с терабайтным data warehouse, гордились управлением цепочками поставок и запасами в реальном времени, предсказанием спроса по погоде и так далее. Но сейчас похоже сдали.
На Rust нельзя описать нормально многие структуры. Нужны либо unsafe, либо проверки в рантайме. Borrow checker ограничен в том, безопасность чего он может доказать. Довольно большой класс безопасных структур он не пропустит, из-за чего в том же Rust много библиотечных классов реализовано на unsafe.
Вы необходимо столкнетесь с чем-то подобным, буду ждать следующих статей как вы это решили.
Тот же full scan нормален на 1 мегабайте, не ОК на допустим 10 Тб. Но где граница, и как сделать так чтобы самый важный запрос не упал, когда самая главная таблица вдруг превысила этот порог на один байт?
Разные No/NewSQL базы тоже стабильные точечные запросы обеспечивают. А вот произвольный SQL не могут, и не видно как это было бы возможно.
В чем-то сходно с Rust, какие-то ограниченные структуры владения объектами можно описать и он гарантирует безопасность. А вот произвольный связи как в плюсах не сделать.
Выбор, и там и там, между универсальностью и гарантиями. В общем для обоих есть применения, но универсальность нужна чаще конечно.
Выше это и не утверждалось, лишь что небольшая смена семантики не позволит избежать borrow checker'а (при декларируемой memory safety).
Одно отличие я заметил, в С++ объект освобождается по выходу из области видимости, а тут иногда раньше, по месту "последнего" использования. Это память в каких-то случаях экономит, но редко. Зато ломает RAII паттерн.
Но разница как-то явно не достаточная чтобы избежать нормального borrow checker. А что компилятор делает если этот указатель передается в другие функции из статьи совсем не ясно.
Я бы даже сказал, что возможно стоит это позиционировать как механизм макросов, на уровне AST, может быть интересным, хотя видны и проблемы. Но это не про исключения.
А какой нибудь практический пример использования таких исключений есть? Не очень понятно, что в примере с делением на ноль можно написать внутри
if (op == 0), кромеterminate(), а это не совсем то что обычно понимают под обработкой исключений. Ну может быть альтернативно установить какой-нибудь глобальный флаг ошибки, вернуть какую-нибудь ерунду, и продолжить вычисления? Тоже так себе идея. Да и сделать оба варианта можно эффективнее без лишнихifчерез системные исключения.Тогда я только хочу пожелать удачи вашим аналитикам в построении отчетов. Медленные индексы наверное наименьшие из их проблем.
Есть дата, когда запись появляется в базе (со всеми оговорками, что могут быть разные задержки, но идея понятна). Думаю что здесь это как раз sold_at, если другая - то надо использовать ее. Обычно по этому же полю происходит чистка базы.
И для этого поля PARTITION BY естественное решение, решающее сразу множество проблем. Для остальных полей очевидно индексы.
В некоторых базах данных, кстати, PARTITION BY по дате заказа ускорит запросы и по дате поставки, они сильно коррелируют. Но, увы, это пока не про Postgres.
Какие лимиты, только три дня назад была новость что продать удалось ровно ноль (0) карт.
https://habr.com/ru/news/1005268/
Все таки в таблице sales поле sold_at одно и весьма специальное. С остальными да.
С ежедневными отчётами, почему борьба за индекс, а не PARTITION BY? Казалось бы, как раз для таких случаев, исключает лишнее сканирование, и решает проблемы с вакуумом и пр.
А то что должна быть возможность отвязать карту там прописано? А то видал сервисы, где последнюю карту не удалить.