Гід з вимови назв баз даних та інструментів
Як правильно вимовляти PostgreSQL, Cassandra, Redis, Elasticsearch, DynamoDB та інші назви технічних інструментів — щоб ви впевнено звучали на кожній зустрічі.
Одним з найпоширеніших джерел сором’язливості для не-рідних носіїв англійської мови на технічних зустрічах є неправильне вимовляння добре відомого інструменту або назви бази даних. Хороші новини в тому, що навіть носії англійської мови не погоджуються з деякими з них — отже, ви не одинокі. Але знання широко прийнятого вимовляння допоможе вам звучати впевнено і підготовлено.
У цьому довіднику наведено найчастіше неправильно вимовлені назви баз даних і інструментів інфраструктури, а також фонетичні посібники і описи, які можна почути.
Імена баз даних
PostgreSQL
** Правильна вимова: ** “post-GRES-cue-el” або, неформально, “post-GRES”
Частина « SQL » вимовляється як окремі літери: S- Q- L, а не « sequel ». Багато інженерів просто кажуть « Postgres » у розмові.
“Ми запускаємо PostgreSQL 15 на головному сервері бази даних.”
- “Просто скажіть « Postgres » — всі зрозуміють, що ви маєте на увазі.” *
** Часта помилка: ** Використання “post-GRAY-skul” або “post-gree-SKU-el.”
MySQL
** Правильное произношение: ** “my-ESS-cue-el”
Ніколи не «my-sequel» — на відміну від Microsoft SQL Server, який традиційно називається «sequel server»
- “Стара система використовує MySQL 5. 7.” *
SQLite
** Правильное произношение: ** “ESS-cue-el-LITE”
“Для локального розроблення ми використовуємо SQLite — не потрібно встановлювати нічого.”
Cassandra
** Правильное произношение: ** “kuh-ZAN-druh”
Наголос на другому складі. Названо на честь грецького міфічного пророка.
- “Ми обрали Cassandra за її пропускну здатність запису і можливості географічного розповсюдження.” *
DynamoDB
** Правильное произношение: ** “Дай-ну-мо-ді-бі”
Розбийте його на частини: dy-na-mo + DB (сказано як окремі літери D-B).
- « Всі дані сеансу користувача зберігаються у DynamoDB з п’ ятихвилинним TTL. » *
Redis
** Правильное произношение: ** “RED-iss”
Короткі і прості — наголос на першому складі. Це скорочення від Remote Dictionary Server.
“Ми використовуємо Redis для кешування відповідей API і керування обмеженнями швидкості.”
Elasticsearch
** Правильное произношение: ** “ee-LAS-tik-search”
Четыре слога. Частина « Elastic » звучить чітко, як англійське слово * elastic *.
“Elasticsearch забезпечує повнотекстовий пошук у нашій документації.”
MongoDB
** Правильное произношение: ** “мон-го-ди-би”
«DB» наприкінці мови називається окремими літерами: D-B.
“Наша система керування вмістом зберігає документи в MongoDB.”
CockroachDB
** Правильное произношение: ** “ПИК-таракан-бджола”
Так, це справді названо на честь комахи. Скажи це з впевненістю.
“Ми оцінили CockroachDB за його можливостями розподіленого SQL.”
Інструменти для обміну повідомленнями та потокового передачі даних
Kafka
** Правильное произношение: ** “KAF-kuh”
Названо на честь письменника Франца Кафки. Наголос на першому складі.
- « Всі події опубліковано у темах Kafka і використовуються службами, що виконують послідовність подій. » *
RabbitMQ
** Правильное произношение: ** “RAB-it-em-cue”
MQ означає Message Queue — скажіть літери M і Q окремо.
- “RabbitMQ обробляє нашу чергу повідомлень електронної пошти.” *
Інструменти інфраструктури
Kubernetes
** Правильное произношение: ** “ку-бер-нет-ез”
Це одне з найчастіше неправильно вимовлених імен у технології. П’ять складів. Часто скорочується до “K8s” в письмі (вимовляється як “kates”).
“Програма запущена на кластері Kubernetes, яким керує EKS.”
Terraform
** Правильное произношение: ** “TER-uh-форма”
Три склади. Як “терраформа” (для перетворення середовища планети).
“Наша інфраструктура визначена як код, що використовує Terraform.”
Nginx
** Правильное произношение: ** “EN-jin-ex”
Цей здивувало багатьох людей. Це не “en-GINKS” або “en-JINKS” — це “en-jin-ex.”
“Nginx служить нашим зворотнім проксі і обробляє закінчення SSL.”
Ansible
** Правильное произношение: ** “АН-сух-бул”
Три склади. Слово походить з наукової фантастики (пристрій для миттєвого спілкування).
“Ми керуємо налаштуваннями сервера за допомогою програм Ansible.”
Швидка посилання таблиця
| Tool | Pronunciation | Notes |
|---|---|---|
| PostgreSQL | post-GRES-cue-el | Often shortened to “Postgres” |
| MySQL | my-ESS-cue-el | Not “my-sequel” |
| Cassandra | kuh-ZAN-druh | Stress on second syllable |
| DynamoDB | DY-nuh-mo-dee-bee | DB = individual letters |
| Redis | RED-iss | Stress on first syllable |
| Kubernetes | koo-ber-NET-eez | Often called “K8s” |
| Nginx | EN-jin-ex | Not “en-GINKS” |
| Kafka | KAF-kuh | Named after Franz Kafka |
Найбезпечніше правило: слухайте, як старші інженери вашої компанії говорять ці імена і слідуйте за ними. У багатьох випадках існують регіональні відмінності — і доки ви будете послідовними і впевненими, люди зрозуміють вас. Вимова важлива не так, як ясність.
На практиці: Навігація нюансів — поза фонетичним посібником
Вимова - це одне; звучатиме як професіонал в технічному контексті - це зовсім інше. Це не тільки про те, щоб голосні звучали правильно, хоча це, безумовно, важливо. Як людина, для якої англійська мова не є рідною, ви, ймовірно, знаєте про тонкі відмінності в ритмі та интонації, які можуть повністю змінити те, як сприймаються ваші слова. Розгляньмо це: трохи непевна мова, навіть з ідеальною вимовою, може бути інтерпретована як невпевненість. І навпаки, надмірно настійлива або швидка мова може бути надмірно зарозумілою або відверто відверто.
Метою не є імітація рідного мовця дословно - це часто неможливо і, чесно кажучи, не корисно. Замість цього, мова йде про прийняття патернів впевненого, чіткого спілкування, що є звичайним у професійних середовищах. Це означає, що вам слід звертати увагу на те, як ви структуруєте речення, особливо коли ви пояснюєте технічні поняття. Наприклад, під час коментаря перегляду коду на запиті на витягування, ви можете почути щось на зразок: «Я помітив, що цей запит використовує повне сканування таблиці для customer_orders. Можливо, ми могли б дослідити додавання індексу на order_date колонці для покращення продуктивності. Це відносно проста зміна і повинна відповідати нашій поточній стратегії індексування. “Зауважте ретельну фразу - визнання проблеми, запропонування рішення і вкладення його в встановлені практики. Уникайте різких заяв на зразок « Цей запит повільний! », які не відповідають контексту і не заохочують співпрацю.
Іншим поширеним сценарієм є обговорення Slack про зміни схеми бази даних. Колега може натиснути: «Гей команда, я просто хотів повідомити, що ми мігруємо таблицю product_details з PostgreSQL до Cassandra. Ми зосередимося на денормалізації часто доступних полів — зокрема, ідентифікаційних кодів та назв продуктів — для оптимізації швидкості читання. Ми також реалізуємо рівень кешування за допомогою Redis, щоб ще більше зменшити навантаження на базу даних. ” Знову ж таки, зверніть увагу на надані деталі і обґрунтування. Це демонструє не тільки знання інструментів, але і розуміння того, * чому * ці вибори були зроблені, відповідно до бізнес-вимог.
Наконец, помни, что ясная произношение создает доверие. Коли хтось може впевнено сформулювати технічні деталі, це сигналізує про компетентність і авторитет - якості, які цінуються в будь-якому професійному середовищі. Не бійтеся запитати про пояснення, якщо ви не впевнені щодо терміну або фрази; справжня цікавість завжди цінується набагато більше, ніж спроба, але в кінцевому підсумку неправильна мова.
Ось простий приклад використання psql для запитів до бази даних:
psql -h your_host -U your_user -d your_database -c "SELECT * FROM product_catalog WHERE category = 'electronics';"