Cassandra数据库不支持as怎么办，有其他的方法么

创建数据库

选择开始菜单中→程序→【Management SQL Server 2008】→【SQL Server Management Studio】命令，打开【SQL Server Management Studio】窗口，并使用Windows或 SQL Server身份验证建立连接。

在【对象资源管理器】窗口中展开服务器，然后选择【数据库】节点

右键单击【数据库】节点，从d出来的快捷菜单中选择【新建数据库】命令。

执行上述 *** 作后，会d出【新建数据库】对话框。在对话框、左侧有3个选项，分别是【常规】、【选项】和【文件组】。完成这三个选项中的设置会后，就完成了数据库的创建工作，

在【数据库名称】文本框中输入要新建数据库的名称。例如，这里以“新建的数据库”。

在【所有者】文本框中输入新建数据库的所有者，如sa。根据数据库的使用情况，选择启用或者禁用【使用全文索引】复选框。

在【数据库文件】列表中包括两行，一行是数据库文件，而另一行是日记文件。通过单击下面的【添加】、【删除】按钮添加或删除数据库文件。

切换到【选项页】、在这里可以设置数据库的排序规则、恢复模式、兼容级别和其他属性。

切换到【文件组】页，在这里可以添加或删除文件组。

完成以上 *** 作后，单击【确定】按钮关闭【新建数据库】对话框。至此“新建的数据”数据库创建成功。新建的数据库可以再【对象资源管理器】窗口看到。

Cassandra数据库中经常会出现“准备重生成”的警告，这通常是因为数据表的大小超过了Cassandra的指定限制，导致数据分布不均匀，进而影响Cassandra集群的性能。

要解决这个问题，您可以执行以下步骤：

1. 检查数据表的大小：使用nodetool命令检查数据表的大小，如果数据表的大小已接近或超过了硬盘空间的限制，则需要考虑添加更多的硬盘空间或重新设计数据模型以减少数据表的大小。

2. 优化数据表：删除不再需要的数据，并检查索引是否正确设置。如果索引设置不当，可以重新创建索引以提高查询性能。

3. 增加节点：如果数据表过大，可以通过添加更多的节点来解决问题。增加节点将分散数据并提高性能。

4. 执行重生成：如果上述步骤都不能解决问题，可以考虑执行重生成 *** 作。不过，在执行重生成之前，务必备份所有的数据，以免数据丢失。

总之，如果您的Cassandra数据库出现“准备重生成”的警告，这意味着需要采取一些措施来优化数据表并提高性能。

Cassandra的配置文件可以对Cassandra中的数据进行配置。cassandra.yaml 中关于存放数据信息的配置如下：

数据信息一共分为以下3类：

在data目录下，Cassandra 会将每一个 Keyspace 中的数据存储在不同的文件目录下，并且 Keyspace 文件

目录的名称与 Keyspace 名称相同。

假设有两个 Keyspace，分别为 ks1 和 ks2，但在 data目录下，将看到3个不同的目录：ks1，ks2和 system。其中 ks1 和 ks2 用于存储系统定义的两个 Keyspace 的数据，另外一个 system 目录是 Cassandra 系统默认的一个 Keyspace，叫做 system，它用来存储 Cassandra 系统的相关元数据信息以及 HINT 数据信息。

当 Cassandra 有数据需要更新时，第一个记录这个更新的地方就是 Commitlog。

Commitlog由如下两个部分构成：

CommitLog - xxx.log 、 CommitLog - xxx.log.header 。

在 CommitLog - xxx.log 文件中，保存了每一次更新 *** 作的值。

在 CommitLog - xxx.log.header 文件中，记录了哪些数据已经从 memtable 中写入 SSTable 中。

通过log. header文件中记录的元数据信息, Cassandra 可以及时删除不必要的Commitlog文件，减少磁盘的占用量，并在Cassandra重启时,加快从Commitlog中恢复数据的速度。

Commitlog文件的大小可以在配置文件中指定，默认是128MB。

当一个Commitlog文件大小超过设置的阈值后，将会新建一个Commitlog,并将更新数据写人这个新的文件中。

Cassandra提供了两种记录Commitlog的方式:周期记录( periodic)和批量记录( batch)。如果使用周期记录的方式，需要在配置文件进行如下配置:

Cassandra会每次更新信息将写人 Commitlog 中，并且每隔一定的时间间隔( commitlog-sync_ period in ms )调用 org apache. cassandra. io. util. BufferedRandomAccessFile. syne() 同步 Commitlog 文件。

如果使用批量记录的方式，需要在配置文件进行如下配置:

Cassandra会缓存每次更新信息，每隔一定的时间间隔( commitlog sync_ batch _window_in_ ms )调用 org. apache. cassandra. io. util. BuferedRandomAccessFile. syne () 同步Commitlog 文件，最后将之前缓存的更新信息写人Commitlog中。

如果不允许数据丢失，可以使用周期的方式记录 Commitlog。如果写入数据量非常大，同时可以承担由于机器可能宕机导致的数据丢失的风险，则使用批量记录的方式记录 Commitlog。

在实际的使用中，可以根据情况来选用合适的 Commitlog记录方式。

数据写入 Commitlog 后，将缓存在 Memtable 中。

Cassandra 中每一个 Memetable 只为一个 ColumnFamily 提供服务。

当下面3个条件中任意个满足后，会将Memtable中缓存的数据写入磁盘，形成一个SSTable文件。

上面提到的3个参数都可以在配置文件中进行设置，Cassandra 为每一个ColumnFamily提供单独的配置。

每当有数据进人 Memtable 中时，会将数据保存到成员变量 ColumnFarmilies 中，并解析这个数据，排除重复或者是已经过期的数据。具体实现如下:

当Cassandra需要将Memtable中缓存的数据写人磁盘时，会按照内存中Key的顺序写人SSTable中。

使用 Memtable 的优势在于：将随机 IO 写变为顺序 IO 写，降低大量的写 *** 作对存储系统的压力。

Cassandra 中的 Memtable 会缓存客户端写入的数据，当Memtable中缓存的某一个ColumnFamily中的数据量( 对应配置文件中的 memtable_ throughput_ in mb 和 memtable_ operations_in_ millions 或者超过上一次生成SSTable的时间(对应配置文件中的 memtable flush_ after_mins )后，Cassandra 会将Memtable中对应的ColumnFamily的数据持久化到磁盘中，生成一个SSTable文件。

如ColumnFamily名称为Cfl的一个SSTable文件由如下文件组成:

其中，“Cf1”为ColumnFamily的名称“e” 为版本的标识(这个标识在0.7之前的版本中是没有的)“1”代表这是名称为Cfl的ColumnFamily的第一个SSTable,这个数字会随着新的SSTable文件的生成不断增加“Data”、“Filter”、 “Index"和“Statistics" 分别代表 SSTable 4个不同组成部分，它们的作用各不相同。

在Cassandra中，除了用户自己定义的 Keyspace 之外，还有一个特殊的 Keyspace :名称为system的系统表空间。

用户不能在 Cassandra 中创建名为 system 的 Keyspace,只能由 Cassandra 系统自动创建。系统表空间的主要有以下两个作用:

如果系统首次启动，Cassandra 将会自动在data目录下创建系统表空间，并将系统元数据信息存放在系统表空间中。以后启动的过程中，Cassandra 将会直接从系统表空间中读取系统元数据信息。

如果 Cassandra 发现某一个节点宕机，就会将发送给宕机节点的数据以 HINT 的形式发送给另外台 Cassandra 服务器。接收到 HINT 数据的 Cassandra 服务器将数据缓存到系统表空间中，当其发现宕机的 Cassandra 恢复后，将缓存 HINT 数据发送给恢复的服务器，完成数据传输后，将缓存的 HINT 数据从系统表空间中删除。

本章从原理上分析和讲解了 Cassandra 的内部数据存储结构Commitlog、Memtable、SSTable和构成SSTable的4个子文件。了解Cassandra的内部数据存储构造有利于为基于Cassandra的应用程序设计合理的数据模型，以及找出造成读写瓶颈的原因。另外还介绍了Cassandra的系统表空间，了解了整个系统元数据管理的机制。

---