Мой подход, к сожалению, не работает с go modules начиная с 1.11, но это должно быть можно исправить :). Поддерживаются любые операционные системы, но go нужно запускать через враппер, который добавляет в каждую функцию проверки, а-ля unconditional jump инструкция, но без привязки к конкретной архитектуре процессора.
Почему Вы пишете комментарии к постам шестилетней давности :)? Если кратко, то индекса по полю price нет, потому что мы в данном примере мы сортируем по любому полю, не только по цене.
Можно добавить индексы по всем полям, но тогда вставка будет ещё медленней, и места на диске таблицы тоже будут занимать ещё больше. При этом ускорение от индексов будет только в случае, если условие WHERE не отсекает слишком много строк, иначе MySQL будет читать всю таблицу случайным чтением по одной строке, что очень медленно.
В ClickHouse же вторичных индексов на тот момент вообще не было.
Вместо редиса можно использовать, скажем, простенький сервис на Go, ибо у редиса будет большой оверхед просто из-за необходимости хранить каждый битмап в отдельном ключе (вместо просто сплошного массива в Go)
На счет битмап индекса: его тоже ведь можно обновлять плавно, например сделать из него LSM-структуру, где новые куски (уже отсортированные) битмап-индекса вставляем в виде отдельного индекса в конец и периодически мержим в один большой. Но это вариант только когда данных очень много, да :). Обычно задержка в несколько минут (или как часто перестраивается индекс) для пользователей не так важна.
Спасибо :). Да, твое решение тоже норм, если искать нужно не по всем полям. Интересное свойство именно кластерного индекса состоит в том, что оно не требует создания отдельной копии данных (для индекса), поэтому в случае, если фильтровать нужно (почти) по всем полям, дополнительный индекс почти ничего не даст.
Согласен, я рассматривал только MySQL, SQLite и Postgres. У первых двух автоинкремент в составе композитного кластерного индекса нельзя определить. В каких-то других базах разве можно?
Это не исключения :). Это обработка ошибок с помощью фичи языка под названим «возврат нескольких значений из функции». Поэтому синтаксис кажется странным.
Молодцы, что написали статью! Не уверен, что я бы стал на вашем месте рекомендовать эту книгу. В приведенных отрывках кода довольно много недочетов, которые лично мне бросились в глаза:
Если не удалось распарсить форму, то это не Internal Server Error. Почти во всех (или вообще во всех) случаях ошибки, которые может вернуть ParseForm, возникают из-за недопустимого формата запроса, например как вот тут
Есть отдельный метод http.Error, который намного компактнее позволяет записывать возврат ошибки в HTTP обработчике: https://pkg.go.dev/net/http#Error
Точно также, здесь если логика вернула ошибку, она не обязательно (но может быть) связана с тем, что что-то пошло не так на стороне сервера. Код логики должен либо дополнительно возвращать нужный HTTP код ошибки, либо возвращать такой тип ошибки, в котором также содержится HTTP статус-код.
Данные в запросе должны экранироваться, лучше всего с помощью структуры url.Values и метода Encode()
defer resp.Body.Close()
if resp.StatusCode != http.StatusOK {
return "", fmt.Errorf("Unexpected status code %d",
resp.StatusCode)
}
Очень распространённая ошибка: тело запроса не вычитывается до конца, если произошла ошибка (не в смысле, что метод .Do() вернул ошибку, а что сервер ответил, но с HTTP кодом отличным от 200. В этом случае (если тело запроса не прочитано) соединение с сервером будет закрыто и keep-alive для соединения не будет работать. Это становится важно, когда запросов к одному и тому же серверу выполняется много: могут даже закончиться исходящие порты на сервере, который отправляет запросы.
Потом значит потомки такие читают архив Хабра за 2022 год и происходит следующий диалог:
Папа, папа, почему новость вроде нормальная, но комментариев к ней нет, даже про дженерики в го, ведь это такая большая новость? И что у гофера с лицом?
Не знаю, сынок, давай посмотрим, что происходило в эти дни в мире
В каком-то смысле должны быть. Собрать приложение на Go с использованием бинарных пакетов больше не выйдет: эту возможность, насколько я помню, относительно недавно выпилили (https://github.com/golang/go/issues/28152 ?). В целом вся система сборки построена вокруг сборки из исходников.
То есть, да, есть плагины, и можно, конечно же, собрать своё приложение из исходных кодов, которые не в опенсорсе, но при этом это всё равно будет сборка из исходных кодов, а не бинарников.
Эта статья показывает, насколько Go, в общем-то, практически принуждает всё делать с открытыми исходниками, за счёт отсутствия стабильного ABI :)
Как производительность? Потому что у macOS есть какое-то особое расширение VNC-протокола, которое динамически подбирает качество JPEG, или что-то такое, и в итоге даже когда выполняются полноэкранные анимации или меняется большое количество всего на экране одновременно, производительность почти не падает, но, конечно, за счёт более низкого качества картинки, пока идет перерисовка.
Интересно, как с этим дела обстоят у xRDP. По моему опыту ничего подобного там нет, к сожалению.
Честно говоря, ни разу не очевидно, что MethodByName() имеет сложность O(N), и, видимо, для большинства других программистов на Go, даже для таких крупных проектов, как Hugo, тоже. Спасибо за статью и за патч! Поставил плюсик issue
Вот кстати вопрос, надо ли это вообще делать. Ибо даже в Max процессоре всего 8 высокопроизводительных ядер, и этого достаточно для подавляющего большинства задач, даже для профессиональной работы. Всё остальное намного эффективнее делать на отдельных ускорителях, те же нейронки или кодирование/декодирование видео. Так что, может, и не будет никакого аналога по количеству ядер Xeon'у, и всё равно его производительность для всех Pro задач будет сильно выше, чем у текущих Mac Pro.
Возможно, идея примерно та же, что и с продажей не очень выгодных товаров (вроде туалетной бумаги) в магазинах: с них, вероятно, ничего не зарабатываешь, но люди неохотно будут ходить в ваш магазин, если этих товаров нет.
То же самое и с VMWare Fusion: если у них не было десктопного продукта для мака, хоть и может не самого классного, то может и серверные решения стали бы выглядеть менее солидно.
Я имел в виду, пользуетесь ли вы где-то фактом того, что вам не нужны удаления во многих случаях, и дает ли это какой-то измеримый выигрыш по сравнению с другими реализациями?
Ну сейчас-то хоть перешли?
Неплохо! Я для интереса тоже как-то делал очень похожее, но чтобы было на уровне исходного кода: https://habr.com/ru/articles/328620/
Мой подход, к сожалению, не работает с go modules начиная с 1.11, но это должно быть можно исправить :). Поддерживаются любые операционные системы, но go нужно запускать через враппер, который добавляет в каждую функцию проверки, а-ля unconditional jump инструкция, но без привязки к конкретной архитектуре процессора.
Почему Вы пишете комментарии к постам шестилетней давности :)?
Если кратко, то индекса по полю price нет, потому что мы в данном примере мы сортируем по любому полю, не только по цене.
Можно добавить индексы по всем полям, но тогда вставка будет ещё медленней, и места на диске таблицы тоже будут занимать ещё больше. При этом ускорение от индексов будет только в случае, если условие WHERE не отсекает слишком много строк, иначе MySQL будет читать всю таблицу случайным чтением по одной строке, что очень медленно.
В ClickHouse же вторичных индексов на тот момент вообще не было.
Да и сейчас наверное ;)
Вместо редиса можно использовать, скажем, простенький сервис на Go, ибо у редиса будет большой оверхед просто из-за необходимости хранить каждый битмап в отдельном ключе (вместо просто сплошного массива в Go)
На счет битмап индекса: его тоже ведь можно обновлять плавно, например сделать из него LSM-структуру, где новые куски (уже отсортированные) битмап-индекса вставляем в виде отдельного индекса в конец и периодически мержим в один большой. Но это вариант только когда данных очень много, да :). Обычно задержка в несколько минут (или как часто перестраивается индекс) для пользователей не так важна.
Спасибо :). Да, твое решение тоже норм, если искать нужно не по всем полям. Интересное свойство именно кластерного индекса состоит в том, что оно не требует создания отдельной копии данных (для индекса), поэтому в случае, если фильтровать нужно (почти) по всем полям, дополнительный индекс почти ничего не даст.
Да, вполне. Про bitmap index, например, есть такая статья: https://habr.com/ru/articles/261137/
Согласен, я рассматривал только MySQL, SQLite и Postgres. У первых двух автоинкремент в составе композитного кластерного индекса нельзя определить. В каких-то других базах разве можно?
Ждем кросс-JIT между PHP FFI JIT и LuaJIT с инлайнингом и прочим.
Это не исключения :). Это обработка ошибок с помощью фичи языка под названим «возврат нескольких значений из функции». Поэтому синтаксис кажется странным.
Молодцы, что написали статью! Не уверен, что я бы стал на вашем месте рекомендовать эту книгу. В приведенных отрывках кода довольно много недочетов, которые лично мне бросились в глаза:
Здесь сразу несколько проблем:
Если не удалось распарсить форму, то это не Internal Server Error. Почти во всех (или вообще во всех) случаях ошибки, которые может вернуть ParseForm, возникают из-за недопустимого формата запроса, например как вот тут
Есть отдельный метод http.Error, который намного компактнее позволяет записывать возврат ошибки в HTTP обработчике: https://pkg.go.dev/net/http#Error
Точно также, здесь если логика вернула ошибку, она не обязательно (но может быть) связана с тем, что что-то пошло не так на стороне сервера. Код логики должен либо дополнительно возвращать нужный HTTP код ошибки, либо возвращать такой тип ошибки, в котором также содержится HTTP статус-код.
Данные в запросе должны экранироваться, лучше всего с помощью структуры url.Values и метода Encode()
Очень распространённая ошибка: тело запроса не вычитывается до конца, если произошла ошибка (не в смысле, что метод .Do() вернул ошибку, а что сервер ответил, но с HTTP кодом отличным от 200. В этом случае (если тело запроса не прочитано) соединение с сервером будет закрыто и keep-alive для соединения не будет работать. Это становится важно, когда запросов к одному и тому же серверу выполняется много: могут даже закончиться исходящие порты на сервере, который отправляет запросы.
Аналогично, нет экранирование значения
Потом значит потомки такие читают архив Хабра за 2022 год и происходит следующий диалог:
Папа, папа, почему новость вроде нормальная, но комментариев к ней нет, даже про дженерики в го, ведь это такая большая новость? И что у гофера с лицом?
Не знаю, сынок, давай посмотрим, что происходило в эти дни в мире
А, вот оно как, оказывается... Понятно
В каком-то смысле должны быть. Собрать приложение на Go с использованием бинарных пакетов больше не выйдет: эту возможность, насколько я помню, относительно недавно выпилили (https://github.com/golang/go/issues/28152 ?). В целом вся система сборки построена вокруг сборки из исходников.
То есть, да, есть плагины, и можно, конечно же, собрать своё приложение из исходных кодов, которые не в опенсорсе, но при этом это всё равно будет сборка из исходных кодов, а не бинарников.
Эта статья показывает, насколько Go, в общем-то, практически принуждает всё делать с открытыми исходниками, за счёт отсутствия стабильного ABI :)
Как производительность? Потому что у macOS есть какое-то особое расширение VNC-протокола, которое динамически подбирает качество JPEG, или что-то такое, и в итоге даже когда выполняются полноэкранные анимации или меняется большое количество всего на экране одновременно, производительность почти не падает, но, конечно, за счёт более низкого качества картинки, пока идет перерисовка.
Интересно, как с этим дела обстоят у xRDP. По моему опыту ничего подобного там нет, к сожалению.
Честно говоря, ни разу не очевидно, что MethodByName() имеет сложность O(N), и, видимо, для большинства других программистов на Go, даже для таких крупных проектов, как Hugo, тоже. Спасибо за статью и за патч! Поставил плюсик issue
Вот кстати вопрос, надо ли это вообще делать. Ибо даже в Max процессоре всего 8 высокопроизводительных ядер, и этого достаточно для подавляющего большинства задач, даже для профессиональной работы. Всё остальное намного эффективнее делать на отдельных ускорителях, те же нейронки или кодирование/декодирование видео. Так что, может, и не будет никакого аналога по количеству ядер Xeon'у, и всё равно его производительность для всех Pro задач будет сильно выше, чем у текущих Mac Pro.
Возможно, идея примерно та же, что и с продажей не очень выгодных товаров (вроде туалетной бумаги) в магазинах: с них, вероятно, ничего не зарабатываешь, но люди неохотно будут ходить в ваш магазин, если этих товаров нет.
То же самое и с VMWare Fusion: если у них не было десктопного продукта для мака, хоть и может не самого классного, то может и серверные решения стали бы выглядеть менее солидно.
Кстати у KPHP, оказывается, есть телеграм канал: https://t.me/kphp_chat
Спасибо за ответ!
Я имел в виду, пользуетесь ли вы где-то фактом того, что вам не нужны удаления во многих случаях, и дает ли это какой-то измеримый выигрыш по сравнению с другими реализациями?