Обращение к издательствам: пожалуйста, ПЕРЕВОДИТЕ термины

eac6f6617a4ebb93c1bbcdabc103e99e.jpg

Эта статья — ответ на статью «Обращение к издательствам: пожалуйста, не переводите термины».

Давайте поговорим, например, о распределённых базах данных. Всем известно, что данные делятся на фрагменты, которые затем распределяются между узлами.

— Какие-такие «узлы» и «фрагменты»? — спросит программист, работающий с MongoDB. — Наверное, ты имел в виду «чанки» и «шарды»?

— Что за «чанки»? — переспросит аналитик, хранящий данные в HBase. — У нас данные делятся на «регионы», которые потом распределяются по «регионсерверам»!

Можно было бы продолжать этот воображаемый спор, но я лучше приведу табличку:

Платформа

Фрагмент

Узел

Apache Ignite/GridGain, Riak KV, Redis, VoltDB

partition

node

Apache Cassandra

virtual node

host

MongoDB, Oracle Sharding Option

chunk

shard

Tarantool/Picodata

bucket

shard

Teradata

Access Module Processor (AMP)

node

Hazelcast

partition

member

SAP HANA

shard

host

HBase

region

regionserver

GreenPlum

segment

host/node

CockroachDB

range

node

YugabyteDB

chunk/shard/tablet

server

Не лучше ли вместо того, чтобы засорять речь десятком англицизмов, договориться, наконец, о своих терминах? Тем более сейчас, когда импортозамещение из шуток в курилках стало наконец-то чем-то большим?

— Ну подумаешь, — скажет воображаемый собеседник, — нашёл один неудачный термин. Но так-то, английский язык — образец точности формулировок и технической строгости!

Да в том-то и дело, что сам по себе язык — не образец. Наличие множества независимых компаний-производителей, развивающих собственные платформы, с одной стороны — благо, но с другой — не очень. Потому что сначала компания пишет код, а потом придумывает называние, не давая себе труда посмотреть, была ли идея реализована раньше, и нет ли у неё готового названия.

Допустим, для построения витрины нам надо прочитать всю таблицу целиком, но запрос содержит некое условие, например, «зарплата больше 100000 рублей». Если система хранения данных достаточно хитрая, то она может снабдить каждый блок данных метаданными, где записаны минимальное и максимальное значения полей. Обнаружив в нашем примере, что максимальное значение поля «зарплата» — 95300, система вообще не будет читать этот блок, потому что в нём заведомо нет интересных данных.

Этот механизм СУБД ClickHouse называет «засечки» (marks). Но разработчик Oracle никаких «маркс» не знает, потому что в Oracle это называется совсем по-другому:

  • storage indexes — Oracle Exadata и Oracle in-memory option;

  • zonemaps — Netezza, Oracle;

  • MinMax indices — VectorWise;

  • segment elimination — SingleStore;

  • synopsis tables — Db2;

  • block range index (BRIN) — PostgreSQL;

  • zone map, storage index, data skipping, constraint exclusion — SAP IQ.

Так почему бы во всех русских книгах не называть засечки засечками?

Ну, а пока суд да дело, сделайте дифференциальную резервную копию вашей БД!

Бьюсь об заклад, что правильно меня поймут только администраторы Oracle. Администраторы Microsoft SQL Server и MySQL будут делать не то, что я попросил, а администраторы PostgreSQL и Db2 просто не поймут просьбу. Всё потому, что «точная и однозначная» английская терминология не точна и не однозначна:

Дифференциальная

Кумулятивная

Oracle

Differential

Cumulative

Postgres Pro

Incremental

Microsoft SQL Server

Differential

IBM Db2

Delta

Incremental

MySQL Enterprise

Incremental

Differential

Percona XtraBackup

Incremental

Incremental

Пишите по-русски. Пожалуйста!

© Habrahabr.ru