【问题标题】:Migrate RDBMS to Cassandra将 RDBMS 迁移到 Cassandra
【发布时间】:2015-11-14 09:28:09
【问题描述】:

我有一个包含以下表格的 RDBMS 数据库:

机场(iata PK、机场、城市、州、国家、纬度、经度)

cancellation_cause(cod_cancellation PK,描述)

制造商(id_manufacturer PK,制造商名称)

型号(id_model PK、model_name、id_manufacturer FK)

航空公司(航空公司代码PK,描述)

airplane_type(id_AirplaneType PK,airplane_type)

engine_type(id_engine PK,engine_type)

Aircraft_type(id_aircraft PK,aircraft_type)

飞机(TailNumber PK、id_model FK、 id_aircraft FK、airline_code FK, id_AirplaneType FK, id_engine FK, Issue_date, status, year)

Flight(id_flight PK、cod_cancellation FK、TailNumber FK、iata_origin FK >, iata_destin FK, Year, Month, DayofMonth, DayofWeek, DepTime, CRSTime, ArrTime, CRSArrTime, FlightNum, AtualElapsedTime, CRSElapsedTime, AirTime, ArrDelay, DepDelay, distance, TaxiIn, TaiOut, Cancelled, Diverted)

注意:PK - 主键; FK - 外键

我正在 RDBMS 和 Cassandra 数据库之间进行比较研究。我的目标是将此数据库迁移到 Cassandra 并在两者中运行一些查询,以便在类似情况下比较两者的性能。

谁能告诉我最好的方法?我应该如何在 Cassandra 中为数据库建模?

【问题讨论】:

  • 为什么要强调PK/FK关系?这对你在 Cassandra 很重要吗?你的测试用例/基准是什么?
  • PK/FK 关系与关系模型有关。我需要将此架构迁移到 Cassandra,并具有必要的差异。在我的测试中,我打算咨询以下内容:注册更多出发延误(DepDelay)的航空公司;覆盖距离更大的飞机类型和发动机类型;飞行时间更长的制造商模型飞机是什么? (通话时间)。我的问题是如何关联数据,因为无法执行 JOIN。
  • -我会尽快详细说明。
  • 谢谢。感谢您的帮助,我在这方面遇到了很多困难。
  • 说吧。我将尝试逐步提供帮助并提供答案。只需继续添加到 cmets 即可。我知道的越多,我就越能完善答案(我会将其保留在答案中,以使其更明显,因此对更广泛的社区更有用)

标签: database-design cassandra database-migration rdbms nosql


【解决方案1】:

Cassandra 查询语言 (CQL) 版本。 3.3 为创建关系表的几乎精确副本提供了语义。这不是最规范的做事方式,但它肯定可以帮助您解决根据 cmets 看起来很紧急的情况。

因此,您可以使用 CQL 创建:

CREATE TABLE airport( id text PRIMARY KEY, airport text,  
  city text, state text, country text, lat float, long float);

然后像这样继续创建其他表。

要将 csv 加载到表中,请使用:

COPY airport (id, airport, city, state, country, lat, long)  
FROM 'airport.csv' WITH DELIMITER = ';' AND HEADER = TRUE;

不是在 Cassandra 中,您可能应该使用 UUID 并在加载值时生成它们。

在我看来飞机可以非规范化,所以我会全部建模 作为一个条目,其中 airplane 是一个超级列,engine 和 type 是列。使用 CQL 3.3,您可以通过这种方式进行建模,也可以采用传统的为每个实体创建表的方式。

详情请参阅post。

注意事项:

关于关系,您可能需要放弃基于主键 (PK)、外键 (FK) 概念和相关硬约束的关系概念。要将数据迁移到 Cassandra NoSQL,您将不依赖硬链接,而是依赖这些实体链接的信任。就像从强类型语言迁移到弱类型语言一样,您将遇到的唯一损失将是数据库确保链接。 您仍然可以拥有您的 ID,您仍然可以维护基于 ID 的链接,但不会有数据库强制完整性约束。您或许可以放弃自动生成的 ID。 以下是一些其他非常适用的阅读材料:

  1. Data modelling best practices 来自 Datastax 的 CQL 3.3 手册。

  2. article 描述了迁移关系模式设计的实践,并介绍了 Cassandra 中的一些通用设计概念。

  3. Migration best practices - 从 RDBMS 到 NoSQL/Cassandra。

  4. Datastax 是 Cassandra 背后的一家商业公司,拥有大量优秀的教育资源和实用建议here。

【讨论】:

  • CQL 3.3 docs 有一些关于使用 Cassandra 进行数据建模的好材料。 tl;dr 版本是您应该围绕查询对表进行建模,特别注意分区和集群键。
猜你喜欢
  • 2017-05-09
  • 1970-01-01
  • 2020-02-13
  • 2013-11-28
  • 2018-08-04
  • 1970-01-01
  • 1970-01-01
  • 2013-07-05
  • 1970-01-01
相关资源
最近更新 更多