• PG2 release 0.1.3: Next.JDBC-compatible API

  Feb 20, 2024 clojure, programming, postgres, sql

  Table of Content

  • Obtaining a Connection
  • Executing Queries
  • Transactions
  • Keys and Namespaces

  PG2 version 0.1.3 is out. One of its new features is a module which mimics Next.JDBC API. Of course, it doesn’t cover 100% of Next.JDBC features yet most of the functions and macros are there. It will help you to introduce PG2 into the project without rewriting all the database-related code from scratch.

  Obtaining a Connection

  In Next.JDBC, all the functions and macros accept something that implements the Connectable protocol. It might be a plain Clojure map, an existing connection, or a connection pool. The PG2 wrapper follows this design. It works with either a map, a connection, or a pool.

  Import the namespace and declare a config:

  (require '[pg.jdbc :as jdbc])
  
  (def config
    {:host "127.0.0.1"
     :port 10140
     :user "test"
     :password "test"
     :dbname "test"})
  

  Having a config map, obtain a connection by passing it into the get-connection function:

  (def conn
    (jdbc/get-connection config))
  

  This approach, although is a part of the Next.JDBC design, is not recommended to use. Once you’ve established a connection, you must either close it or, if it was borrowed from a pool, return it to the pool. There is a special macro on-connection that covers this logic:

  (jdbc/on-connection [bind source]
    ...)
  

  If the source was a map, a new connection is spawned and gets closed afterwards. If the source is a pool, the connection gets returned to the pool. When the source is a connection, nothing happens when exiting the macro.

  (jdbc/on-connection [conn config]
    (println conn))
  

  A brief example with a connection pool and a couple of futures. Each future borrows a connection from a pool, and returns it afterwards.

  (pool/with-pool [pool config]
    (let [f1
          (future
            (jdbc/on-connection [conn1 pool]
              (println
               (jdbc/execute-one! conn1 ["select 'hoho' as message"]))))
          f2
          (future
            (jdbc/on-connection [conn2 pool]
              (println
               (jdbc/execute-one! conn2 ["select 'haha' as message"]))))]
      @f1
      @f2))
  
  ;; {:message hoho}
  ;; {:message haha}
  

  Executing Queries

  Two functions execute! and execute-one! send queries to the database. Each of them takes a source, a SQL vector, and a map of options. The SQL vector is a sequence where the first item is either a string or a prepared statement, and the rest values are parameters.

  (jdbc/on-connection [conn config]
    (jdbc/execute! conn ["select $1 as num" 42]))
  ;; [{:num 42}]
  

  Pay attention that parameters use a dollar sign with a number but not a question mark.

  The execute-one! function acts like execute! but returns the first row only. Internaly, this is done by passing the {:first? true} parameter that enables the First reducer.

  (jdbc/on-connection [conn config]
    (jdbc/execute-one! conn ["select $1 as num" 42]))
  ;; {:num 42}
  

  To prepare a statement, pass a SQL-vector into the prepare function. The result will be an instance of the PreparedStatement class. To execute a statement, put it into a SQL-vector followed by the parameters:

  (jdbc/on-connection [conn config]
    (let [stmt
          (jdbc/prepare conn
                        ["select $1::int4 + 1 as num"])
          res1
          (jdbc/execute-one! conn [stmt 1])
  
          res2
          (jdbc/execute-one! conn [stmt 2])]
  
      [res1 res2]))
  
  ;; [{:num 2} {:num 3}]
  

  Above, the same stmt statement is executed twice with different parameters.

  More realistic example with inserting data into a table. Let’s prepare the table first:

  (jdbc/execute! config ["create table test2 (id serial primary key, name text not null)"])
  

  Insert a couple of rows returning the result:

  (jdbc/on-connection [conn config]
    (let [stmt
          (jdbc/prepare conn
                        ["insert into test2 (name) values ($1) returning *"])
  
          res1
          (jdbc/execute-one! conn [stmt "Ivan"])
  
          res2
          (jdbc/execute-one! conn [stmt "Huan"])]
  
      [res1 res2]))
  
  ;; [{:name "Ivan", :id 1} {:name "Huan", :id 2}]
  

  As it was mentioned above, in Postgres, a prepared statement is always bound to a certain connection. Thus, use the prepare function only inside the on-connection macro to ensure that all the underlying database interaction is made within the same connection.

  Transactions

  The with-transaction macro wraps a block of code into a transaction. Before entering the block, the macro emits the BEGIN expression, and COMMIT afterwards, if there was no an exception. Should an exception pop up, the transaction gets rolled back with ROLLBACK, and the exception is re-thrown.

  The macro takes a binding symbol which a connection is bound to, a source, an a map of options. The standard Next.JDBC transaction options are supported, namely:

  • :isolation
  • :read-only
  • :rollback-only

  Here is an example of inserting a couple of rows in a transaction:

  (jdbc/on-connection [conn config]
  
    (let [stmt
          (jdbc/prepare conn
                        ["insert into test2 (name) values ($1) returning *"])]
  
      (jdbc/with-transaction [TX conn {:isolation :serializable
                                       :read-only false
                                       :rollback-only false}]
  
        (let [res1
              (jdbc/execute-one! conn [stmt "Snip"])
  
              res2
              (jdbc/execute-one! conn [stmt "Snap"])]
  
          [res1 res2]))))
  
  ;; [{:name "Snip", :id 3} {:name "Snap", :id 4}]
  

  The Postgres log:

  BEGIN
  SET TRANSACTION ISOLATION LEVEL SERIALIZABLE
  insert into test2 (name) values ($1) returning *
    $1 = 'Snip'
  insert into test2 (name) values ($1) returning *
    $1 = 'Snap'
  COMMIT
  

  The :isolation parameter might be one of the following:

  • :read-uncommitted
  • :read-committed
  • :repeatable-read
  • :serializable

  To know more about transaction isolation, refer to the official [Postgres documentation][transaction-iso].

  When read-only is true, any mutable query will trigger an error response from Postgres:

  (jdbc/with-transaction [TX config {:read-only true}]
    (jdbc/execute! TX ["delete from test2"]))
  
  ;; Execution error (PGErrorResponse) at org.pg.Accum/maybeThrowError (Accum.java:207).
  ;; Server error response: {severity=ERROR, message=cannot execute DELETE in a read-only transaction, verbosity=ERROR}
  

  When :rollback-only is true, the transaction gets rolled back even there was no an exception. This is useful for tests and experiments:

  (jdbc/with-transaction [TX config {:rollback-only true}]
    (jdbc/execute! TX ["delete from test2"]))
  

  The logs:

  statement: BEGIN
  execute s1/p2: delete from test2
  statement: ROLLBACK
  

  The table still has its data:

  (jdbc/execute! config ["select * from test2"])
  
  ;; [{:name "Ivan", :id 1} ...]
  

  The function active-tx? helps to determine if you’re in the middle of a transaction:

  (jdbc/on-connection [conn config]
    (let [res1 (jdbc/active-tx? conn)]
      (jdbc/with-transaction [TX conn]
        (let [res2 (jdbc/active-tx? TX)]
          [res1 res2]))))
  
  ;; [false true]
  

  It returns true for transactions tha are in the error state as well.

  Keys and Namespaces

  The pg.jdbc wrapper tries to mimic Next.JDBC and thus uses kebab-case-keys when building maps:

  (jdbc/on-connection [conn config]
    (jdbc/execute-one! conn ["select 42 as the_answer"]))
  
  ;; {:the-answer 42}
  

  To change that behaviour and use snake_case_keys, pass the {:kebab-keys? false} option map:

  (jdbc/on-connection [conn config]
    (jdbc/execute-one! conn
                       ["select 42 as the_answer"]
                       {:kebab-keys? false}))
  
  ;; {:the_answer 42}
  

  By default, Next.JDBC returns full-qualified keys where namespaces are table names, for example :user/profile-id or :order/created-at. At the moment, namespaces are not supported by the wrapper.

  For more information, please refer to the official README file.

• PG2 release 0.1.2: more performance, benchmarks, part 3

  Feb 6, 2024 clojure, programming, postgres, sql

  Table of Content

  • Introduction
  • Test1. Reading a single-column random query
  • Test2. Reading a multi-column, complex random query
  • Test3. Reading random JSON
  • Test 4. Connection pools
  • Test 5. Forcibly evaluate each row after reading
  • Test 6. Benchmarking the HTTP server with various -c values
    • 1 concurrent request
    • 16 concurrent requests
    • 64 concurrent requests
  • Summary

  Introduction

  The PG2 library version 0.1.2 is out. One of its features is a significant performance boost when processing SELECT queries. The more fields and rows you have in a result, the faster is the processing. Here is a chart that measures a query with a single column:

  

  No difference between the previous release of PG and the new one. But with nine fields, the average execution time is less now:

  

  Briefly, PG2 0.1.2 allows you to fetch the data 7-8 times faster than Next.JDBC does. But before we proceed with other charts and numbers, let me explain how the new processing algorithm works.

  Read more →

• Gzip

  Jan 26, 2024 programming, gzip

  Коллеги, используйте gzip! Это простой способ уменьшить трафик в разы, если не на порядок. Буквально двумя строчками можно превратить гигабайты CSV в 200-300 мегабайтов. Разве не чудо? И делается это парой строк.

  Теперь подробней. Gzip — старый алгоритм потокового сжатия. Ключевое слово “потоковый”. Это значит, алгоритму не нужен файл целиком; он читает окно байтов и выдает сжатое окно. За счет этого можно пережать любой поток, в том числе бесконечный.

  В джаве потоки байтов используют часто. В ней легко втиснуть GzipInputStream или GzipOutputStream, чтобы закодировать или декодировать поток. Например, если источник сжат Gzip, то обернем его так:

  (-> "some.file.gzip"
      (io/file)
      (io/input-stream)
      (GzipInputStream.))
  

  При чтении получим нормальный текст. А чтобы закодировать поток, делаем иначе: навесим на выходной поток GzipOutputStream и колбасим в него. Только в конце надо вызвать .finish, чтобы добить незавершенное окно.

  (let [out (-> "myfile.out.gzip"
                io/file
                io/input-stream)
        gzip (new GzipOutputStream out)]
    (while ...
      (.write gzip <bytes>))
    (.finish gzip))
  

  Удивляет, что при всей банальности gzip используют мало. А ведь он отлично подходит для текстовых данных: HTML, JSON, CSS, JS, CSV. В текущем проекте сервисы гоняют гигабайты CSV и JSON, и хоть кто-нибудь подумал о сжатии…

  Простой эксперимент: несжатый CSV — 146 мегабайтов, сжатый — 26. Почти в шесть раз. Даже если закодировать результат в base64, это даст +30% от 26 мегабайтов, то есть всего 35. Выгода все равно 4 раза. В том же Nginx сжатие gzip включается одной строкой в конфиге.

  Еще больше мою веру укрепил крит на проде. Один из сервисов выплюнул 6 мегабайтов JSON, что не помещается в квоту AWS Lambda. Пришлось в спешке прикручивать сжатие, чтобы сообщенька пролезла.

  Соответственно, бесят HTTP-клиенты, которые ничего не знают о Gzip. Работа с ними превращается в ад: сам проверь заголовки, сам закодируй-раскодируй… и в проекте используется именно такой! Он читает ответ как строку, не проверяя Content-Encoding, и если там gzip, получается чешуя. Авторам — большой ай-ай за игнор веб-стандартов.

  Чем раньше вы возьмете gzip в проект, тем лучше. Потом все равно придется, но будет больно.

• Женские истории

  Jan 25, 2024 women, sex

  Когда читаю женские истории — Твиттер, блоги, журналистику, — вижу один и тот же паттерн:

  • он мне не нравился, но я осталась на свидании;
  • он мне не нравился, но мы целовались;
  • он мне не нравился, но мы поехали к нему;
  • он мне не нравился, но у нас был секс.

  То есть он всю дорогу не нравился, но программа шла по плану — от кафе до постели.

  Тут два момента: либо женщина и правда не знает, что если человек не нравится, то и секс с ним будет плохим. Надеюсь, теперь она это знает.

  Либо женщина все знает, но понимает, что в данный момент на мужчину лучше она рассчитывать не может. Поэтому все, что случилось, выставляется как одолжение с ее стороны.

  Чем раньше женщина прервет эту цепочку, тем лучше.

• Изображая ответственность

  Jan 25, 2024 life

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

  И вот бомба готова, ее забирают вояки, чтобы взорвать над городом. Гибнет двести тысяч человек. ВНЕЗАПНО ученый чувствует ответственность. Пока не умерли эти двести тысяч, кто сгорев, кто разлагаясь от лучевой болезни, ответственности не было. А тут появилась. Пропали сон и аппетит, начинаются походы в высшие инстанции: господин Президент, я чувствую ответственность.

  Словом, бред. Лети в Японию и расскажи погибшим про свою ответственность.

  Почему это нормально для фильма, ясно: историю всегда натягивают на драму. Неважно, про что фильм: бомба, война, политика — на первом месте стоит личная драма, иначе зрители не пойдут. Кроме того, зрителя подводит время. Два года создания бомбы сжаты до 40 минут, и для нас с вами она появляется внезапно: еще пять минут назад не было, а сегодня уже на стенде.

  К фильмам у меня нет претензий за этот штамп. Сняли и ладно. Но раздражает, когда псевдо-ответственность появляется в реальной жизни.

  Скажем, один из разработчиков Постгреса разразился плачем: жаль, что лицензия не позволяет запретить Постгрес в России. Ведь наверняка их армия применяет нашу базу. Срач вышел знатный, и даже пришел основатель проекта, чтобы унять активиста.

  Я не имею отношения к российской армии, но уверен: там используется и Постгрес, и Мария, и Питон, и Перл, и Плюсы и тысячи протоколов и стеков. Ровно как и в другой армии мира. Но если ты хочешь запретить, то где точность? Программист должен мыслить точно. Запрещай конкретно армии России. Почему под запрет попадает детский сад, где сервер 1С крутится на Постгресе?

  Далее, как быть с евреями, которые еще месяц назад обрушали дома с палестинскими детьми? Как-то не очень гуманно. Будем отзывать лицензии у всех фирм Израиля?

  Когда Китай скажет “Тайвань наш” и начнет свою “спецоперацию”, будем отзывать Постгрес у Китая? А потом возвращать по итогам переговоров?

  Еще есть плохие парни вроде торговцев оружием, наркотиками и CP. Свои дела они тоже хранят в базах данных, запрещай ты им или нет.

  Если думать об этом системно, задача становится слишком сложной. Кто-то должен трекать новости и решать, у кого сегодня мы отзываем, а кому возвращаем. Кто будет этим заниматься? Разработчик? Останется ли у него время на разработку после этих вопросов? Если поручить это секретарю, где гарантия, что он правильно истолкует повестку дня?

  Все потому, что с разработчиком случился казус из заголовка. ВНЕЗАПНО он почувствовал ответственность. Захотелось решать, кому можно пользоваться базой, а кому нельзя.

  Похожая история была с другим разработчиком, как ни странно, тоже связанным с Постгресом. У него на сайте был хороший парсер EXPLAIN ANALYSE, но затем автор закрыл доступ из России и Беларуси. Его спросили: зачем? Он накатал телегу про танки в Чехословакии. Так запрети доступ танковым войскам РФ. Зачем всем запрещаешь? Какую проблему ты пытаешься решить?

  Казалось бы, программисты — люди с точным мышлением, а в жизни все наоборот: в голове кисель.

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

  Вариант с псевдо-ответственностью лжив от начала до конца. Он ситуативен и основан на реакции, в нем нет идеи и своей повестки. Это желание попасть в тренд: Гугл-Эпл запрещают, а я чем хуже?

  Если вы хороший разработчик, прошу вас, не становитесь плохим Оппенгеймером. Косплей на великого человека будет крайне неудачным.

  Поэтому: не ищите ответственности там, где ее нет. Просто делайте то, что вы делаете хорошо. Соблюдать этот принцип несмотря ни на что — уже большая ответственность.

• Вложенность

  Jan 25, 2024 programming, nesting

  Об этом никто не пишет, а ведь проблема серьезная. Я говорю о лишней вложенности данных. Недавний пример:

  {:manager
   {:risk
    {:time "10:30"
     :task-id 100400}}
   :accounter
   {:business
    {:time "12:35"
     :task-id 100500}}}
  

  Это вложенная мапа: на первом уровне роль менеджера, на втором тип апрува, на третьем — детали апрува: дата и ссылка на задачу. Спрашивается, зачем было группировать события по роли и типу? Какой смысл? Почему не записать два события:

  [{:role :manager
    :type :risk
    :time "10:30"
    :task-id 100400}
   {:role :accounter
    :type :business
    :time "12:35"
    :task-id 100500}]
  

  Плоско, понятно, нет вложенности. Кому надо, сгруппируют и по роли, и по дате, и бог знает как еще. А когда сгруппировано до нас, сперва нужно распутать, а потом группировать как надо.

  Второй пример: есть мапа с ключом children, в которой вектор мап. В каждой мапе — айдишка и имя:

  {:children
   [{:id 1 :name "test1"}
    {:id 2 :name "test2"}
    {:id 3 :name "test3"}]}
  

  Нужно построить индекс id => name, чтобы потом по нему искать. Я быстренько прошел по children и собрал словарь:

  {1 "test2"
   2 "test2"
   3 "test3"}
  

  На проде — сплошные промахи мимо индекса. Что такое? Оказалось, не до конца прокрутил файлик. У некоторых children есть свои children, то есть структура такая:

  {:children
   [{:id 1 :name "test1"}
    {:id 2 :name "test2"}
    {:id 3 :name "test3"}
    {:id 4
     :name "test4"
     :children
     [{:id 5
       :name "test5"}
      {:id 6
       :name "test6"
       :children
       [...]}]}]}
  

  При этом ограничения в глубину нет: может быть два уровня, может двадцать.

  Вот опять: кто этот гений, который сгруппировал? Как ты будешь это обходить? Ладно у меня Кложа, я написал (tree-seq :children :children data) и готово. А на каком-нибудь Питоне или Джаве голову сломаешь – тут дерево с обходом, нужен стек или очередь. Алгоритмы!

  Сделай ты плоский список и добавь parent_id. Кому надо, построит иерархию:

  [{:id 1 :name "test1"}
   {:id 2 :name "test2"}
   {:id 3 :name "test3"}
   {:id 4 :name "test4"}
   {:id 5 :name "test5" :parent-id 4}
   {:id 6 :name "test6" :parent-id 5}]
  

  И такое постоянно. Беру любой JSON и вижу, как его можно упростить, убрав лишнюю вложенность. Вдвойне обидно, что на эту вложенность кто-то тратил время, а она не нужна!

  Особенно я не люблю, когда вкладывают равнозначные сущности. Например, у нас два автора и у каждого две книги. JSON выглядит так:

  [{:id 1
    :name "John Smith"
    :books
    [{:id 20
      :title "The Best Novels"}
     {:id 30
      :title "Poems"}]}
   {:id 2
    :name "Sam Doe"
    :books
    [{:id 40
      :title "Some Story"}
     {:id 50
      :title "Achieves"}]}]
  

  Что если нужны не книги по авторам, а просто все книги? Опять ходи собирай.

  Я придумал способ как бороться такими случаями. О нем — в следующий раз.

• Поза лотоса

  Jan 25, 2024 life, idiots, designers, lotus

  

  Когда я вижу программиста в позе лотоса, в голове играет сюжет.

  К автору картинки приезжает особая команда. Обученные люди сажают автора в позу лотоса и дают ноутбук. Его заставляют работать в этой позе час. За попытку встать, размяться, подвигать шеей — избиение ноутбуком по голове, а отсчет времени сбрасывается.

  Глядишь, так дизайнеры отучатся рисовать программиста в позе лотоса!

• Мальчик и птица

  Jan 25, 2024 movies, anime

  Я знал, что этого делать не следует, но сделал — сходил на мульт “Мальчик и птица”. Будет много скепсиса и спойлеров, я предупреждал.

  Писать о мультике тяжело. Хаяо Миядзаки — гений и наше все, поэтому любая критика в его адрес — что карикатуры на Мухаммеда: порвут на части. Я не буду критиковать мастера, а только опишу ощущения от просмотра.

  Начнем с того, что фильму не повезло с названием. В оригинале он называется “Как поживаете?” — это заголовок книги, по которой он снят. Однако связи между сюжетом и названием нет. Лишь один раз герой находит книгу с таким заголовком и благополучно забывает о ней. Кто и как поживает — не ясно.

  

  В американском прокате мульт назвали “The boy and the heron” — мальчик и цапля. Это правильно, потому что мальчика и (псевдо)цаплю мы видим большую часть фильма. И хотя у слова “heron” однозначный перевод — цапля, Карл!, — в русском прокате она стала птицей. Эта претензия не к Миядзаки, а к переводчикам.

  В целом, мульт страдает от тех же проблем, что и второй Аватар. При запредельном качестве картинки в нем никакой сюжет, все скомкано и ситуативно. Зрителя отвлекает миллион незначащих деталей. Досадно, что бюджет спустили на визуальную красоту, попустившись смыслом.

  

  Мульт идет 2 часа 10 минут — не так уж и мало. Первые 40 минут — это топтание на тему “не ходи в запретное место”. Понятно, что когда ребенку говорят не ходить куда-то, он пойдет, вопрос в том, как скоро. Но с этим большая затяжка.

  Когда герой входит в запретное место, начинается фантасмагория. Каждые десять минут он проваливается в новый мир со своими причудами. Мелькают локации, существа, загадочные сцены. Все это красиво, но требует ответов: кто это, откуда, зачем и что если? Режиссер не считает нужным все это объяснять; он забрасывает героя в новую локацию, где другие существа, враги и друзья. Словно летишь на карусели и видишь только мелькание.

  

  Иногда режиссер дает отдохнуть: показывает пять минут, как девушка режет хлеб, мажет маслом и ест. Ме-е-едленно и основа-а-ательно. Без музыки, только звон посуды и скрип пола. Красиво, но опять же — назрел миллион вопросов, может, объясните хоть что-нибудь? А бутерброд потерпит.

  Если вы думаете, что я цепляюсь зря, то вот малая толика вопросов:

  • Зачем герой рассек голову камнем?
  • Зачем мачеха пошла в башню?
  • Почему нельзя входить в родильную комнату?
  • Почему мачеха гонит героя прочь?
  • Какую роль играл нерожденный ребенок? Его хотели забрать? Кто и зачем?
  • Какую цель преследовал король попугаев?
  • Что за камни, из которых колдун строил башню? Почему они злые?
  • Что за хранитель гробницы? Почему его не показали?
  • Это все один мир или разные?
  • Если парень в мире мертвых — он умер?
  • Мать парня умерла в больнице или вознеслась на небо, потому что была огненным духом?
  • Что стало в параллельном мире после апокалипсиса?
  • Куда делся дед-колдун? Кто унаследовал его?

  Этих вопросов я могу написать пару экранов, но не вижу смысла. Спрашиваю вас: может быть, из всей этой каши надо было выбрать что-то одно и хорошенько его проработать? А не вываливать на голову, как тарелку с лапшой.

  

  Как я уже говорил, сюжету не хватает целостности: непонятно, какую проблему решает герой. Он отправился в башню, чтобы спасти мачеху, однако:

  • на чердаке он находит послание умершей матери — книгу “Как поживаете?”. Что там написано и какую роль играет находка — не ясно.

  • В мире мертвых живут забавные пузыри, которые улетают и становятся людьми. Этих пузырей жрут пеликаны. Показана сцена, где они слопали почти все пузыри. Как это относится к мачехе? Мы ее спасаем или нерожденных людей?

  • В мире мертвых живет женщина-рыболов, при этом она вовсе не мертвая. Что она там делает и зачем помогает герою — непонятно.

  • В другом мире живет горящая девочка, которую приносят в жертву главному колдуну. Намекается, что девочка — сестра мачехи и мать героя в мире людей. Как все это связано, можно только гадать.

  В сюжете напутаны сложные отношения: смущение подростка перед молодой мачехой, отстранение от отца, наставничество колдуна. Все это эпизодически, ситуативно, без малейшей проработки.

  Пожалуй, главное: нет морали. Совершенно не ясно, от чего предостерегает режиссер. Как жить, чтобы это не повторилось? Или наоборот: все, что случилось — хорошо? Где ориентиры?

  

  Изумила пара сцен:

  • отец дает беременной жене чемодан со словами “осторожно, он тяжелый”. После чего смотрит, как она тащит его в коляску. Помочь беременной жене? Не слышали.

  • Парнишка бьет себя камнем по голове, из нее вытекает ЛИТР крови. Парень спокойно идет домой. Хотел бы я это видеть. Нельзя было как-то реалистичней? Как писал выше, тема самонаказания не раскрыта.

  Словом, если вы смотрели другие мульты Миядзаки, сходите на “Мальчика и птицу” из чувства долга: все-таки прощальный мульт. Недочеты можно списать на фирменный стиль автора: кроме него таких мультов (почти) никто не делает. В отрыве от остального творчества Миядзаки мульт затянут и скучноват. Очень на любителя.

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

• PG2 benchmarks, part 2

  Jan 24, 2024 clojure, programming, postgres, sql

  Table of Content

  • Introduction
  • Test 1. Sending 1000 requests in series
  • Test 2. Sending 1000 requests with concurrency of 16
  • Test 3. Sending 1000 requests with concurrency of 64

  In the previous post, I was measuring bare query/execute/copy functions of the library. Although it’s useful, it doesn’t render the whole picture because it’s unclear how an application will benefit from faster DB access.

  This post covers the second group of benchmarks I made: a simple HTTP server that reads random data from the database and responds with JSON. The benchmark compares PG2 and Next.JDBC as before.

  Introduction

  Some general notes: the server uses Ring Jetty version 1.7.1, JVM 21, Ring-JSON 0.5.1 for middleware. The handles are synchronous. The application uses connection pools for both libraries, and the pools are opened in advance when the server gets started. The maximum allowed pool size is 64. HTTP requests are sent by the ab utility with different -n and -c keys; the -l flag is always sent.

  Read more →

• PG2 early announce and benchmarks, part 1

  Jan 22, 2024 clojure, programming, postgres, sql

  TL;DR: https://github.com/igrishaev/pg2

  Table of Content

  • Introduction
  • How the benchmarks were made
  • Test 1. Querying a single-column, series-based query with 50000 rows
  • Benchmark 2. A complex, multi-column, randomly generated SELECT query
  • Test 3. Querying randomly generated JSON
  • Test 4. Inserting a single row with no transaction
  • Test 5. Inserting a row in a transaction
  • Test 6. COPY IN a vast CSV file from disk
  • Test 7. Copy IN a collection of rows in CSV format
  • Test 8. Copy IN a collection of rows in binary format
  • Test 9. COPY OUT a table into an OutputStream
  • Test 10. Measuring connection pools

  Introduction

  During the last year, I was working on PG — JDBC-free PostgreSQL driver in pure Clojure. By purity it means, there is only a TCP socket to read and write bytes according to the official PostgreSQL protocol, and nothing more.

  It was fun: the very idea of implementing something low-level in Clojure was a challenge. I’ve made a series of tricks to squeeze the performance: mutable collections in favour of Clojure’s ones, special macros to traverse collections using Iterator and .forEach, and so on. After all, my driver was about 1.5 times slower than Next.JDBC, and I still think there is room for further improvement.

  One may ask what is the point of making a driver from scratch in 2024. The reason is, I’m still missing plenty of Postgres features when working with it from Clojure. Namely:

  • no built-in JSON support. In every project, I’ve got to extend some protocols with PGObject, encode and decode the JSON manually;

  • no COPY support. In Postgres, COPY IN/OUT is one of the best features I can remember. But there is no built-in CSV nor binary encoding, for example.

  • Poor time support: selecting a timestamp returns an instance of java.sql.Timestamp which is based on java.util.Date: a mutable object deprecated in Java 1.1.

  • Poor array support: only a certain number of types, no multidimensional arrays, etc.

  • No built-in connection pool.

  Today I deprecated the PG project in favour of PG2. This is a successor of PG(one), my second attempt to make a JDBC-free driver for Postgres. This time around, it’s written completely in Java with a thin Clojure layer. I’ve made some benchmarks and it looks like PG2 2-3 times faster than Next.JDBC. There is no documentation yet, only integration tests that cover plenty of cases (I borrowed the old tests and improved then). Although the documentation is highly required, I could not wait to announce PG2 and share the benchmarks.

  How the benchmarks were made

  I’ve got three Mac devices with core i5, i9, and ARM M1 processors. On each device, I’ve got PostgreSQL installed. All the settings are default, no changes are made. JVM is version 21 although the 16th is the minimum version. The benchmarks are made with Criterium version 0.4.6.

  There are two types of benchmarks, actually. In the first group, I measure query/execute functions using the Criterium framework. In the second group, I’m running a simple HTTP server using Ring + Jetty + JSON and measuring requests per second with Apache Benchmark (ab). For each test, I show the source code with a chart and comments.

  The source code of benchmarks can be found in the repository.

  Read more →

← Страница 5 из 75 →