[00:01] рано или поздно сталкивается каждый разработчик.  Ваше приложение собирает данные с временными метками, и PostgreSQL прекрасно с ними справляется, пока таблица не достигает нескольких сотен миллионов строк, после чего всё рушится.  В этом видео я покажу вам, как масштабные реальные системы
[00:15] решают именно эту проблему, используя самый экстремальный пример, который мне удалось найти, — сеть зарядных станций для электромобилей.  Сейчас это генерирует более 630 миллиардов строк данных в год, и я даже создал собственную сеть зарядных станций с сотнями
[00:28] виртуальных зарядных устройств, чтобы показать вам, как это работает и как вы можете использовать эти ускорения работы вашей базы данных. Хорошо.  Таким образом, в США количество из этих станций, по сути, представляет собой компьютер с сетевым подключением, который
[00:45] Теперь все эти зарядные устройства используют протокол OCPP. .  А если посмотреть, что именно передается по этому соединению, то окажется, что там четыре типа данных.  Итак, сначала вам нужно определить показания счетчиков.  Итак, подумайте о
[00:59] напряжении, токе, мощности, энергии.  Теперь каждое зарядное устройство круглосуточно отправляет показания примерно через 15-30 секунд после подключения к каждой розетке .  Это довольно тяжелое изделие.  Этот отправляет данные. Во-вторых, у нас есть сеансы зарядки.   Вот тогда-то
[01:14] автомобиль к розетке.  То есть, когда автомобиль подключается к зарядке, начинается новая сессия.  Теперь, когда вы показания счетчика за эту сессию будут определять, сколько вам будет выставлено за пользование.  Таким образом, это, по сути, данные для выставления счетов.  А это ведь тоже деньги, верно?  Потому что
[01:28] сумму.  Таким образом, вы не можете потерять эту информацию или допустить ошибку.   И наконец, в-третьих, обновления статуса.  Итак, товар доступен, зарядка неисправна.  Вот так парковке вышло из строя,
[01:41] скучные данные конфигурации.  Итак, модель, прошивка, сколько существует розеток?  Вы поняли идею.  А теперь представьте, как масштабировать все это.  Сеть из 10 000 зарядных устройств, отправляющая показания каждые 30 секунд, генерирует около 20 000 строк
[01:56] данных в секунду, понятно?  Таким образом, это примерно 630 миллиардов строк в год.  И настоящая сложность заключается в том, что показания приборов и данные для выставления счетов — это совершенно разные типы данных, но они должны сосуществовать.
[02:09] Потому что в тот момент, когда клиент оспаривает счет, вам необходимо объединить оба запроса в одном .  Итак, возникает вопрос: как же на самом деле хранить 630 миллиардов строк данных?  Первый вариант — использовать обычный PostgreSQL.  Итак, у вас есть одна большая таблица,
[02:22] временной метке.  И поначалу это отлично работает , что, собственно, и делает это опасным.  Потому что по мере того, как таблица разрастается до сотен миллионов строк, в памяти, вставка данных начнет замедляться, и каждый запрос к панели мониторинга
[02:36] превратится в сканирование всей таблицы, которая буквально занимает место на жестком диске.  Таким образом, в таких масштабах это произойдет не через годы, а через несколько недель. Второй вариант — это то, что
[02:48] обычно выбирает большинство команд.  Поэтому они разделили данные. Они помещают показания в специализированную базу данных временных рядов, возможно, что-то вроде InfluxDB, а данные о выставлении счетов хранят в Postgres.  Звучит вполне разумно.  У вас есть два инструмента,
[03:00] .  Но вот запрос, который окончательно разрушает эту схему.  Например, кто-то оспаривает платеж в размере 40 долларов.  Для разрешения этого спора вам потребуется их платежная документация, а также фактические показания счетчика электроэнергии за этот
[03:14] сеанс зарядки.  Это объединение двух разных таблиц.  Но данные о выставленных счетах PostgreSQL, а показания счетчика — в другой базе данных.  И вы не сможете эффективно объединить данные из двух разных баз данных.  Таким образом, теперь вы фактически
[03:26] запрашивать данные с обеих сторон, сопоставлять их, пытаться сопоставить временные метки и надеяться, что все совпадет.  И вам приходится поддерживать этот код вечно, что довольно раздражает. Теперь третий вариант — поместить всё это в такую ​​библиотеку, как MongoDB.
[03:40] отсутствует реальное сжатие и нет возможности пропускать данные по временному диапазону.  А это значит, что ваши расходы на хранение будут расти бесконечно. И кстати, это ведь не просто проблема зарядных устройств для электромобилей, верно?  Датчики IoT,
[03:54] журналы серверов, финансовые данные, аналитика пользователей, верно?  Любой объект с постоянно увеличивающейся временной меткой в конечном итоге столкнется с этим же препятствием. Данное видео спонсируется компанией Tiger Data. И это потому, что они создали Timescale
[04:06] DB, стандартное решение с открытым исходным кодом для решения именно этой проблемы. что Timescale DB — это не новая база данных, просто расширение для PostgreSQL, поэтому вы используете тот же SQL-код, тот же диск, те же инструменты,
[04:21] активируете его буквально одной строкой кода.  Таким образом, это меняет способ хранения данных, особенно для временных рядов, подобных этим. И реальные компании используют именно такой рабочий процесс с Timescale DB.  Например,
[04:35] одна энергетическая компания сжала 15 терабайт данных до одного и сократила свои расходы на базу данных с 9000 долларов в месяц до всего лишь четырех.  Теперь еще один пользователь заменил им четыре отдельные базы данных и получил примерно в 350 раз более быстрые запросы.
[04:49] вам покажу в этой демонстрации, работает на платформе Tiger Cloud, которая является бесплатная пробная версия, кредитная карта не требуется, и вы можете запустить базу данных примерно за описании на случай, если вы захотите посмотреть, но, конечно, давайте перейдем
[05:03] к демонстрации, и я хочу показать вам, как это работает на самом деле, чтобы вы могли увидеть, как обрабатывать такие огромные объемы данных.  Итак, сейчас я я запустил бесплатный сервис на платформе Tiger Cloud и написал симулятор, который
[05:17] функционирует как настоящая сеть зарядных станций.  Сейчас доступно 500 виртуальных зарядных устройств и 875 розеток. городам.  У нас есть как быстрые , так и медленные зарядные устройства, и виртуальные автомобили могут подключаться, отключаться, начинать и останавливать сеанс зарядки, в общем,
[05:31] вы поняли идею. Здесь я моделирую каждую секунду реального времени, или, другими словами, 30 секунд смоделированного времени, и вы увидите, что у нас есть, например, электропитание сети, и здесь доступны все различные зарядные устройства.  Я
[05:44] происходит, есть ли зарядное устройство, если оно неисправно, я могу нажать на кнопку, и мы сможем увидеть, что произошло, и получим все журналы и данные.  Сейчас одновременно, и если я перейду сюда, мы увидим, что
[06:01] размер постоянно растет во время работы симуляции.  Опять же, это призвано дать вам представление о том, что произойдет, если у нас будет даже 10 000 зарядных устройств, то есть в эту базу данных будет поступать гораздо больше данных.  Итак,
[06:14] показать вам, как выглядит эта симуляция и как мы можем обрабатывать такой объем схему базы данных и различные таблицы, которые я здесь создал.  Есть три основных момента, которые я хотел бы рассмотреть. Первая таблица содержит показания счетчиков, и именно она
[06:28] буквально завалена данными, потому что каждое показание с каждого зарядного устройства попадает в эту таблицу.  Таким образом, буквально каждую секунду и бесконечно много строк появляются сотни строк. И здесь вы можете заметить, что это
[06:40] обычная таблица PostgreSQL.  Единственное, что в нём особенного, добавил снизу.  Итак, вот эта строка: create hypertable. Эта строка указывает TimescaleDB автоматически разделить эту таблицу на
[06:54] более мелкие части в фоновом режиме. В частности, он изготавливает один экземпляр в день. причина, по которой это важно, довольно проста.
[07:07] фрагмент данных за вчерашний день, вместо того чтобы перебирать всю таблицу целиком.  Теперь вам не просто пишете эту одну строку, которую я вам здесь показал, и это произойдет автоматически специально для данных временного ряда.
[07:19] Теперь рассмотрим вторую таблицу, содержащую данные о сеансах тарификации, и именно она включает в себя всю информацию о выставлении счетов.  Таким образом, для каждой сессии зарядки указывается одна строка: кто заряжал, когда сколько энергии использовал, и за какую сумму будет выставлен счет
[07:32] .  И посмотрите, это совершенно стандартная обычная таблица PostgreSQL.  В нем есть первичный ключ, у нас есть ссылки на внешние ключи , ничего особенного, верно?  И это сделано намеренно, потому что данные о выставлении счетов — это не огромный объем информации, который поступает непрерывно
[07:44] .  Это обычные реляционные данные, и мы можем держать их под контролем. фрагмента данных могут храниться в одной и той же базе данных, и в этой схеме я могу А третья таблица — это таблица событий состояния.  По сути, это и есть
[07:59] состояние зарядного устройства меняется — доступно, неисправно, заряжается и т.д. — здесь будет появляться новая запись.  Теперь у нас также есть гипертаблица, поскольку она может содержать больше здесь много информации.  То же самое , это всего одна строка, что
[08:13] значительно ускоряет выполнение запроса. Здесь есть еще несколько запросов и таблиц, три основные таблицы, о которых нам нужно знать.  Итак, если я вернусь к симуляции, я увижу, что она всё ещё работает.  Мы все еще собираем данные, и
[08:25] это будет выглядеть на самом деле.  Машины въезжают, машины выезжают, сессия информацию, снимаем показания датчиков, и все это одновременно добавляется в нашу базу данных.  На данный момент база данных
[08:39] непрерывно заполняется и добавляется по 1100 или 1200 строк в секунду, и её размер вам и показывал.  А если вы хотите увидеть, например, случайный счет от пользователя, мы Таким образом, вы можете увидеть, например, информацию о случайном клиенте: когда он подключился к сети, сколько времени
[08:55] и сколько ему было выставлено счетов. И это позволяет нам получить полные всё ещё смотрите, возникает очевидный вопрос: Postgres, и если да, то насколько ?  И я хочу показать вам несколько реальных
[09:10] примеров, чтобы вы могли увидеть, насколько сильно отличается скорость работы, если просто включить эту единственную функцию в TimescaleDB.  Итак, для этого данные, которые у меня уже есть.  Итак, я просто приостановлю симуляцию и
[09:23] обычную базу данных Postgres, в которой не включена функция TimescaleDB.  Так что там просто когда я, знаете, определял схему.  Итак, я нажму эту кнопку, несколько минут, а затем я выполню те же запросы, те же
[09:37] объединения, все то же самое с этим другим типом данных, и вы увидите, в чем на также сколько места это занимает, потому что, как вы увидите, с Timescale DB это занимает гораздо меньше места.  Итак, создание обычной базы данных Postgres завершилось, и
[09:50] выглядят вот так, и я сейчас объясню, почему.  Таким образом, в обычной PostgreSQL — 2,85 ГБ, в Timescale DB — 3,47 ГБ.  Причина, по которой база данных Timescale DB сейчас больше, заключается в том, что я еще не сжал таблицу.  В Timescale DB есть
[10:04] встроенная функция, позволяющая сжимать любые данные временных рядов, что уменьшает их размер.  Как видите, у нас уже создано восемь фрагментов, потому что здесь уже заполнены данные за восемь дней, и каждый день будет автоматически создаваться новый фрагмент, но мы
[10:17] ничего не сжимали.  В отличие от обычного PostgreSQL, где таблица новая, в ней нет лишних данных, поэтому она выглядит немного меньше, и мы можем это проверить на панели мониторинга Tiger Cloud , хорошо?  Итак,
[10:29] гипертаблицу и покажу вам, сколько места мы фактически экономим, когда нажмем кнопку.  Это позволит сжать наши гипертаблицы.  К вашему сжимать таблицы. Например, вы можете добавить
[10:44] сжимать таблицы.  Я этого не сделал, потому что это симуляции, но теперь, благодаря ручному сжатию, вы через минуту увидите, сжатие только что завершилось. Из-за текущих настроек обработали только первые шесть фрагментов
[10:58] , но, как видите, фактически размер уменьшился примерно до 30% от первоначального, то есть 3,46 теперь стало 1,23 .  Просто применив это два других фрагмента, то получим ещё примерно 25% прироста, и
[11:12] общий размер файла составит менее 1 ГБ. Итак, первое преимущество заключается в том, сколько места это фактически занимает при включенном сжатии.  Хорошо, теперь перейдем к следующему сравнению, которое, на мой взгляд, имеет гораздо большее значение, а именно к выполнению
[11:24] выполню несколько запросов и покажу, как это выглядит в базе данных с поддержкой Timescale DB по сравнению с обычной базой данных PostgreSQL.  Итак, сначала я создам панель мониторинга автопарка.  Итак, эта программа
[11:36] проанализирует все показания, вычислит среднюю мощность для каждого зарядного устройства, показателей мощности.  Таким образом, системе приходится просматривать практически всю таблицу, и именно этот будет выполнять каждая операционная панель мониторинга.  Итак, вы увидите, что при запуске этого процесса
[11:50] как в обычной версии PostgreSQL, так и в Timescale DB.  И, как вы можете видеть, если присмотреться, вот какая разница в скорости получается.  Итак, обратите внимание, что обрабатывает все показания мощности из таблицы и вычисляет их как среднее значение для каждого
[12:04] зарядного устройства.  В обычной версии PostgreSQL это заняло почти 17 секунд, что замедлило получение результата.  В базе данных Timescale это заняло 5,4 секунды, а при использовании я также настроил в базе данных , мы получили около 1,7 секунды.  Таким образом,
[12:19] , мы получили около 1,7 секунды.  Таким образом, DB значительно ускоряет процесс, в 10 раз.  А если я открою это, вы увидите, что сводная информация выглядит примерно так, создать представление, которое будет постоянно обновляться, чтобы
[12:32] нам было еще быстрее получать эти данные, используя данные временной шкалы .  Суть непрерывного агрегирования заключается в том, что Timescale DB хранит небольшую сводную таблицу с почасовыми данными по каждому зарядному устройству, и затем
[12:44] автоматически обновляет эту сводку по мере поступления новых данных. Таким образом, вашей панели мониторинга никогда не нужно просматривать все 24 миллиона строк таблицу, что и обеспечивает высокую скорость работы.  Дело в том, что сводная
[12:57] таблица практически не увеличивается в размерах, поэтому всё это будет работать чрезвычайно быстро, даже когда количество строк достигнет миллиардов.  Однако, используемая со временем становится все медленнее, поскольку сжатие данных не
[13:10] каждый раз считывать всю базу данных целиком.  Теперь мы можем сделать то же самое с очень похожие результаты.  Как видите, здесь мы получаем очень похожие результаты. PostgreSQL, 5,3 секунды.  Timescale DB, 1,9 секунды.  И мы получаем один и тот же ответ в
[13:25] обоих случаях, используя запрос подобного рода.  Хорошо.  Теперь перейдем к следующему сравнению, которое касается спора по поводу выставленного счета, с которого я, собственно, и начал это видео.  Представьте, что неверный, я не использовал столько электроэнергии, и так далее».  Для решения этого вопроса
[13:39] вам понадобятся две вещи.  Вам нужен счет, который хранится в таблице сессий, и зафиксированные счетчиком в момент подключения автомобиля, которые находятся в таблице показаний, содержащей около 24 миллионов строк данных. Теперь, если вы помните, я ранее
[13:52] упоминал о раздельной конфигурации, где у нас было две отдельные базы данных, и о том, как приходилось объединять множество кода, чтобы фактически извлечь эти данные.   В данном случае мы можем выполнить всего один SQL-запрос, и
[14:04] счету.  Например, если я возьму здесь случайную купюру, мы посмотрим на объединена.  Итак, ответ мы получаем довольно быстро .  У нас есть зарядном устройстве, о времени подключения, а также все
[14:19] Здесь отображаются все данные показаний датчика.  Как видите, за эти 28 минут мы получили 56 показаний мощности, по одному каждые 30 секунд, что и составляет эти 56 показаний.  Мы можем проверить их, подтвердить, суммировать все
[14:32] потребленные нами электроэнергию, и получить данные о киловатт-часах прямо здесь, чтобы убедиться, что счет и показания действительно совпадают.  Честно говоря, если вам найти последние показания зарядного устройства , и у вас есть хороший индекс, то обычный
[14:46] понятно?  И скорость вставки будет очень похожей.  Теперь, когда их 20 миллионов существовать, мы всё ещё можем получать информацию, но помните, что мы говорим о легитимных сетях, которые могут содержать миллиарды, в случае
[15:00] сетей зарядки электромобилей — 630 миллиардов строк, верно?  Это примерно в 35 000 раз больше, , и при таком масштабе разница в объеме памяти, о которой я говорю, — это Непрерывное агрегирование — все это не просто приятные дополнения
[15:14] , это буквально разница между работающей базой данных и той, недель, когда данные полностью заполнятся.   А теперь всего две вещи, которые стоит знать.  Всё, что вы только что видели, работает на самом маленьком экземпляре
[15:26] Tiger Cloud, который они предлагают.  Как видите, у меня всего 2 ГБ оперативной памяти, верно?  И используется самый маленький экземпляр.  Также трансляция ведётся с моего компьютера через общедоступный интернет.  Теперь, при желании, вы также можете настроить автоматическое перемещение всех старых данных
[15:38] в недорогие хранилища S3 вместо того, чтобы они оставались на этом устройстве, и при этом они по-прежнему будут доступны для запросов в зависимости от настроек Tiger Data. Теперь Tiger также имеет коннектор MCP, а это значит, что вы можете подключить эту
[15:50] или Cursor, и позволить искусственному интеллекту управлять ею автоматически.  Таким образом, он может создавать .  Именно так я и запустил этот полноценный проект, для которого Cloud автоматически добавляя данные.  Вы поняли идею.
[16:05] Хорошо.  Итак, честно говоря, после всего этого я пришел к выводу, что если вы собираетесь работать с данными временных рядов, то включение чего-то вроде Timescale DB — это совершенно очевидное решение.  Для
[16:21] вам ничего менять не нужно .  И, конечно же, если вы хотите, чтобы все в таких сервисах, как Tiger Cloud, ссылку на который я оставлю в этом видео.  Если вам понравилось,
[16:34] канал, и увидимся в следующем видео! next one. >> [music]