Не, слабый сервер (с учетом того что это Windows) - это конечно не оправдание, но я пытался значительно позже (2015 примерно) на виртуалке с 4 ядрами и 4Gb оперативки записать лог транзакций с мосбиржи, не так и много, где-то миллионы в сутки примерно было нужно. Оказалось, что дисковый массив у нас тоже общий, и всего выдерживает 4000IOPS примерно, а мы в одиночку с нашей базой захотели порядка 5000. При этом переезд на нормальный сервер через полгода сделал эту задачу почти тривиальной. В общем, для MS SQL мало ресурсов - иногда реально мало ресурсов.
Ну что это именно 2007 - вышло как-то не очевидно. Но в целом я вас понял, наверное не самая крупная база, но при ограничениях на память и процессор, и очевидно без SSD - не самая мелкая. Два ядра - это вообще ну очень фигово, я бы сказал.
в обычный месяц приходится 30 тысяч ордеров о потерянных сумках, в сезон отпусков - 90 тысяч.
Вы 3 тысячи записей в день называете что-ли быстрорастущей базой? А если нет, то к чему был этот пример? Даже если умножить это на число аэропортов в мире (возьмем от фонаря 10000), даже это не будет большим объемом.
Работать вы будете в команде, как правило вполне себе среднего размера, общаться со своим начальником и еще десятком людей. Ну может сотней, но это уже на уровне лида, и редко. И именно эти люди, а вовсе не компания, будут определять для вас все. Ну может не вообще все, но большую часть ваших успехов, все чему вы научитесь, будете ли вы довольны работой, как вы будете зарабатывать, и прочая и прочая - все это в основном определяется тем, какова ваша команда. Компания на это разумеется тоже влияет, но достаточно опосредовано.
Мораль? В заголовке надо заменить компанию мечты на команду.
Все это написано с позиции рядового сотрудника или лида, возможно у условного CEO командой мечты действительно является компания - но я лично никогда не рвался ни в какие CEO.
Не уловил, от чего спасает? Мы вообще-то изначально говорили о желательности и необходимости понимания того, "как оно внутри работает". Если некий хомо сапиенс знает про 302 и 301, он обычно читал документацию, и его уже не надо спасать :)
Я просто его привел как пример того, что очень часто попадается реально на глаза. Т.е. это - некое непонимание принципов работы (протокола, браузера, бэкенда в связке), которое приводит к таким вот косякам в работе вполне реальных сайтов.
Повторная отправка формы это вторично. Первично то, что я обновляю страницу. И при этом происходит повторная отправка формы.
Очень просто они связаны. Есть классический паттерн - после обработки POST нужно делать редирект на GET, чтобы такого не было. Если этого не сделано - человек который писал бэкенд очевидно не очень хорошо понимает, как это работает в связке. Причина в том, что результат GET кешируется (может кешироваться).
Заметьте, что там написано про tenant encryption key, т.е. это конечно разговор про шифрование и пр. - но скорее применительно к облакам, где вы можете случайно (ну или неслучайно) получить доступ к чужим данным, когда в облаке много разных компаний. Т.е. речь о защите скорее базы целиком, нежели отдельных записей. Это вполне реальный случай, и к нам наши безопасники регулярно с такими вопросами приходят - но это другой случай.
Но я быстро прочитал, если вы там видите что-то другое - ткните пальцем, это правда интересно.
Я понимаю что у вас может быть все иначе. Если у вас есть кому учить джунов систематически - наверняка входные параметры джунов могут быть другими.
Просто я исхожу из того, что сценарий когда браузер меня спрашивает "будем форму еще раз постить" после обновления страницы я вижу слишком часто, гораздо чаще чем мне бы хотелось. Т.е. людей, которые пишут сайты, и не понимают вот этой вот разницы между постом и гетом - их, увы, дофига. И это понимание "как работает" - на мой взгляд оно быстро в голову не вкладывается, тут надо читать именно книги, вдумчиво. Нужно ли это всем - да, вопрос без очевидного ответа.
Я присоединюсь к предыдущему оратору. Непонимание работы HTTP - достаточно типично. И если у вас речь про веб разработку (что очевидно исходя из ваших требований), это и есть именно "понимание того, как оно работает внутри". И я боюсь что этому за два часа не научить. И это будет потом всплывать так или иначе багами.
По-моему почти все (ну или многие) практически существующие (для постгреса, для определенности) системы шифрования предполагают, что ключ у клиента. Просто потому, что одно из применений шифрования - это защита данных от админа в том числе. Я бы посмотрел, как вы будете распространять клиентам (особенно если их число заранее неизвестно) вновь выпускаемые ключи, и управлять удаляемыми ключами для удаленных строк.
Ну т.е. я не хочу сказать, что это сделать невозможно, но это далеко нетривиальная задача, которую, как мне кажется, никто реально не решил, и готового такого решения на рынке нет. Я могу ошибаться разумеется, потому что исхожу просто из документации на постгрес, где предлагается пяток примерно решений для шифрования, ни одно из которых под ваше описание не подходит. Если по-простому - то везде один ключ на базу. Даже до ключа на таблицу никто не доходит (хотя по-хорошему, как раз ролевая модель с правами на уровне таблиц, она достаточно типична, и в ней ключ на таблицу был бы логичен).
Да в общем-то примерно так же. Разница с нашим в том, что мне нужно сравнить схему базы в источнике (это одна из трех СУБД разного вида) и реплике (это Apache Hive), где у колонок разные типы данных, некоторых типов вообще в реплике нет, репликация происходит без внешних ключей и скажем индексов, и т.п. Ну т.е. в чем-то у нас проще, в чем-то сложнее. В сущности, есть набор запросов для выборки данных про схему (для источников там есть и запросы про ключи, партиционирование и т.п.), а потом некая надстройка над всем этим, которая проверяет, что скажем числовые типы там и там не просто равны (это иногда невозможно), а совместимы, т.е. множество значений целевого типа шире чем у исходного.
Разве ключ для расшифровки у вас свой для каждой [удаляемой] строки? Скорее всего нет, поэтому задача к этому не сводится. Я могу себе условно представить один ключ на таблицу, и выкинуть его при удалении строк ни никак не получится.
Идея-то насчет шифрования хорошая, но похоже непрактичная.
Я прекрасно представляю, насколько сложно проверить структуру - у меня это одна из задач немаленького приложения. Так что уточню, что я вовсе не имел в виду, что вы что-то делаете не так.
Не, я скорее не конкретно про вас, а в общем. У конкретного человека вполне может быть любая хорошая мотивация, учить вообще интересно, но с ограничениями: учить интересно, когда ученики сами мотивированы. А если вам скажем недостаточно платят - то вопрос финансовой мотивации уже преподавателя встанет в полный рост.
Ну т.е., я согласен что в одном частном случае такой проект вполне может получиться, хотя учить одному десять человек... ну я бы не взялся, хотя у меня опыт преподавания с 1981 года. А вот масштабировать такой проект, чтобы это был поток обучаемых - вот тут вопрос.
Я вас вероятно разочарую, но это боюсь невозможно. В смысле, то что автор тут описывает. В реальной работе вы приобретаете опыт в коллективе, который состоит из команды опытных сотрудников, и одного вас - студента. А то что автор тут реализует - это команда из студентов (непонятного, видимо разного, уровня подготовки), и одного опытного сотрудника.
Один опытный на десяток начинающих - просто не справится с такой задачей. Особенно если студентов еще и мотивировать чем-то надо. Более того, мне с самого начала стало явно, что и этого преподавателя вовсе не очевидно, чем можно замотивировать.
Условной характеристикой качества SQL запроса будем считать количество INNER JOIN в нем
Берем простой запрос с подзапросом (WITH сгодится). Внутри WITH пишем оконную функцию. Снаружи - WHERE, для отбора например 1 записи. Имеем фуллскан, потому что постгрес не умеет проталкивать предикаты в подзапрос, если там есть оконная функция (не знаю, для каких версий это верно). То есть, в запросе вообще нет JOIN, но он ужасно неэффективен.
Я ваши оговорки чуть ниже этой фразы видел, но это все равно фигня. Методика не останется той же самой, если заменить число джойнов на другую метрику. Если бы план запроса было так просто построить - каждый дурак и писал бы оптимизаторы этого плана. Единственный работающий способ - это попросить у СУБД план запроса при помощи EXPLAIN, опять же с оговорками, что в некоторых случаях время выполнения будет таким же, как для выполнения запроса, а потом этот план научиться анализировать (это не является чем-то невозможным). Вот уже из плана (постгрес умеет отдавать его во вполне разбираемом виде типа JSON или ямл) можно понять, эффективен ли запрос - хотя бы взять кост, который тоже те еще попугаи - но это попугаи на базе данных СУБД, а не выдумок.
Не, слабый сервер (с учетом того что это Windows) - это конечно не оправдание, но я пытался значительно позже (2015 примерно) на виртуалке с 4 ядрами и 4Gb оперативки записать лог транзакций с мосбиржи, не так и много, где-то миллионы в сутки примерно было нужно. Оказалось, что дисковый массив у нас тоже общий, и всего выдерживает 4000IOPS примерно, а мы в одиночку с нашей базой захотели порядка 5000. При этом переезд на нормальный сервер через полгода сделал эту задачу почти тривиальной. В общем, для MS SQL мало ресурсов - иногда реально мало ресурсов.
Ну что это именно 2007 - вышло как-то не очевидно. Но в целом я вас понял, наверное не самая крупная база, но при ограничениях на память и процессор, и очевидно без SSD - не самая мелкая. Два ядра - это вообще ну очень фигово, я бы сказал.
Вы 3 тысячи записей в день называете что-ли быстрорастущей базой? А если нет, то к чему был этот пример? Даже если умножить это на число аэропортов в мире (возьмем от фонаря 10000), даже это не будет большим объемом.
Работать вы будете в команде, как правило вполне себе среднего размера, общаться со своим начальником и еще десятком людей. Ну может сотней, но это уже на уровне лида, и редко. И именно эти люди, а вовсе не компания, будут определять для вас все. Ну может не вообще все, но большую часть ваших успехов, все чему вы научитесь, будете ли вы довольны работой, как вы будете зарабатывать, и прочая и прочая - все это в основном определяется тем, какова ваша команда. Компания на это разумеется тоже влияет, но достаточно опосредовано.
Мораль? В заголовке надо заменить компанию мечты на команду.
Все это написано с позиции рядового сотрудника или лида, возможно у условного CEO командой мечты действительно является компания - но я лично никогда не рвался ни в какие CEO.
Не уловил, от чего спасает? Мы вообще-то изначально говорили о желательности и необходимости понимания того, "как оно внутри работает". Если некий хомо сапиенс знает про 302 и 301, он обычно читал документацию, и его уже не надо спасать :)
Я скорее комментировал вот эту вот фразу. Непосредственно к отличиям GET от POST она наверное не относится.
Я просто его привел как пример того, что очень часто попадается реально на глаза. Т.е. это - некое непонимание принципов работы (протокола, браузера, бэкенда в связке), которое приводит к таким вот косякам в работе вполне реальных сайтов.
Повторная отправка формы это вторично. Первично то, что я обновляю страницу. И при этом происходит повторная отправка формы.
Очень просто они связаны. Есть классический паттерн - после обработки POST нужно делать редирект на GET, чтобы такого не было. Если этого не сделано - человек который писал бэкенд очевидно не очень хорошо понимает, как это работает в связке. Причина в том, что результат GET кешируется (может кешироваться).
Заметьте, что там написано про tenant encryption key, т.е. это конечно разговор про шифрование и пр. - но скорее применительно к облакам, где вы можете случайно (ну или неслучайно) получить доступ к чужим данным, когда в облаке много разных компаний. Т.е. речь о защите скорее базы целиком, нежели отдельных записей. Это вполне реальный случай, и к нам наши безопасники регулярно с такими вопросами приходят - но это другой случай.
Но я быстро прочитал, если вы там видите что-то другое - ткните пальцем, это правда интересно.
Я понимаю что у вас может быть все иначе. Если у вас есть кому учить джунов систематически - наверняка входные параметры джунов могут быть другими.
Просто я исхожу из того, что сценарий когда браузер меня спрашивает "будем форму еще раз постить" после обновления страницы я вижу слишком часто, гораздо чаще чем мне бы хотелось. Т.е. людей, которые пишут сайты, и не понимают вот этой вот разницы между постом и гетом - их, увы, дофига. И это понимание "как работает" - на мой взгляд оно быстро в голову не вкладывается, тут надо читать именно книги, вдумчиво. Нужно ли это всем - да, вопрос без очевидного ответа.
Я присоединюсь к предыдущему оратору. Непонимание работы HTTP - достаточно типично. И если у вас речь про веб разработку (что очевидно исходя из ваших требований), это и есть именно "понимание того, как оно работает внутри". И я боюсь что этому за два часа не научить. И это будет потом всплывать так или иначе багами.
По-моему почти все (ну или многие) практически существующие (для постгреса, для определенности) системы шифрования предполагают, что ключ у клиента. Просто потому, что одно из применений шифрования - это защита данных от админа в том числе. Я бы посмотрел, как вы будете распространять клиентам (особенно если их число заранее неизвестно) вновь выпускаемые ключи, и управлять удаляемыми ключами для удаленных строк.
Ну т.е. я не хочу сказать, что это сделать невозможно, но это далеко нетривиальная задача, которую, как мне кажется, никто реально не решил, и готового такого решения на рынке нет. Я могу ошибаться разумеется, потому что исхожу просто из документации на постгрес, где предлагается пяток примерно решений для шифрования, ни одно из которых под ваше описание не подходит. Если по-простому - то везде один ключ на базу. Даже до ключа на таблицу никто не доходит (хотя по-хорошему, как раз ролевая модель с правами на уровне таблиц, она достаточно типична, и в ней ключ на таблицу был бы логичен).
Да в общем-то примерно так же. Разница с нашим в том, что мне нужно сравнить схему базы в источнике (это одна из трех СУБД разного вида) и реплике (это Apache Hive), где у колонок разные типы данных, некоторых типов вообще в реплике нет, репликация происходит без внешних ключей и скажем индексов, и т.п. Ну т.е. в чем-то у нас проще, в чем-то сложнее. В сущности, есть набор запросов для выборки данных про схему (для источников там есть и запросы про ключи, партиционирование и т.п.), а потом некая надстройка над всем этим, которая проверяет, что скажем числовые типы там и там не просто равны (это иногда невозможно), а совместимы, т.е. множество значений целевого типа шире чем у исходного.
Разве ключ для расшифровки у вас свой для каждой [удаляемой] строки? Скорее всего нет, поэтому задача к этому не сводится. Я могу себе условно представить один ключ на таблицу, и выкинуть его при удалении строк ни никак не получится.
Идея-то насчет шифрования хорошая, но похоже непрактичная.
Я прекрасно представляю, насколько сложно проверить структуру - у меня это одна из задач немаленького приложения. Так что уточню, что я вовсе не имел в виду, что вы что-то делаете не так.
Jira расширяется. Плагинами. Пишутся они на Java. Go тут при том, что написанные плагины можно будет выкинуть на помойку.
Абсолютно бессмысленная статья...
Не, я скорее не конкретно про вас, а в общем. У конкретного человека вполне может быть любая хорошая мотивация, учить вообще интересно, но с ограничениями: учить интересно, когда ученики сами мотивированы. А если вам скажем недостаточно платят - то вопрос финансовой мотивации уже преподавателя встанет в полный рост.
Ну т.е., я согласен что в одном частном случае такой проект вполне может получиться, хотя учить одному десять человек... ну я бы не взялся, хотя у меня опыт преподавания с 1981 года. А вот масштабировать такой проект, чтобы это был поток обучаемых - вот тут вопрос.
Я вас вероятно разочарую, но это боюсь невозможно. В смысле, то что автор тут описывает. В реальной работе вы приобретаете опыт в коллективе, который состоит из команды опытных сотрудников, и одного вас - студента. А то что автор тут реализует - это команда из студентов (непонятного, видимо разного, уровня подготовки), и одного опытного сотрудника.
Один опытный на десяток начинающих - просто не справится с такой задачей. Особенно если студентов еще и мотивировать чем-то надо. Более того, мне с самого начала стало явно, что и этого преподавателя вовсе не очевидно, чем можно замотивировать.
Аналогично. Как раз хотел автору намекнуть, что описываемый кейс скорее всего типичен, но далеко не универсален.
Берем простой запрос с подзапросом (WITH сгодится). Внутри WITH пишем оконную функцию. Снаружи - WHERE, для отбора например 1 записи. Имеем фуллскан, потому что постгрес не умеет проталкивать предикаты в подзапрос, если там есть оконная функция (не знаю, для каких версий это верно). То есть, в запросе вообще нет JOIN, но он ужасно неэффективен.
Я ваши оговорки чуть ниже этой фразы видел, но это все равно фигня. Методика не останется той же самой, если заменить число джойнов на другую метрику. Если бы план запроса было так просто построить - каждый дурак и писал бы оптимизаторы этого плана. Единственный работающий способ - это попросить у СУБД план запроса при помощи EXPLAIN, опять же с оговорками, что в некоторых случаях время выполнения будет таким же, как для выполнения запроса, а потом этот план научиться анализировать (это не является чем-то невозможным). Вот уже из плана (постгрес умеет отдавать его во вполне разбираемом виде типа JSON или ямл) можно понять, эффективен ли запрос - хотя бы взять кост, который тоже те еще попугаи - но это попугаи на базе данных СУБД, а не выдумок.