Эта статья – ответ на статью «Обращение к издательствам: пожалуйста, не переводите термины».
Давайте поговорим, например, о распределённых базах данных. Всем известно, что данные делятся на фрагменты, которые затем распределяются между узлами.
– Какие-такие «узлы» и «фрагменты»? – спросит программист, работающий с 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 |
Пишите по-русски. Пожалуйста!