Ⅰ 大数据量的系统的数据库结构如何设计

1、把你表中经常查询的和不常用的分开几个表，也就是横向切分
2、把不同类型的分成几个表，纵向切分
3、常用联接的建索引
4、服务器放几个硬盘，把数据、日志、索引分盘存放，这样可以提高IO吞吐率
5、用优化器，优化你的查询
6、考虑冗余，这样可以减少连接
7、可以考虑建立统计表，就是实时生成总计表，这样可以避免每次查询都统计一次
mrzxc 等说的好，考虑你的系统，注意负载平衡，查询优化，25 万并不大，可以建一个表，然后按mrzxc 的3 4 5 7 优化。 速度，影响它的因数太多了，且数据量越大越明显。
1、存储 将硬盘分成NTFS格式，NTFS比FAT32快，并看你的数据文件大小，1G以上你可以采用多数据库文件，这样可以将存取负载分散到多个物理硬盘或磁盘阵列上。
2、tempdb tempdb也应该被单独的物理硬盘或磁盘阵列上,建议放在RAID 0上，这样它的性能最高,不要对它设置最大值让它自动增长
3、日志文件 日志文件也应该和数据文件分开在不同的理硬盘或磁盘阵列上，这样也可以提高硬盘I/O性能。
4、分区视图 就是将你的数据水平分割在集群服务器上，它适合大规模OLTP,SQL群集上，如果你数据库不是访问特别大不建议使用。
5、簇索引 你的表一定有个簇索引，在使用簇索引查询的时候，区块查询是最快的，如用between，应为他是物理连续的，你应该尽量减少对它的updaet,应为这可以使它物理不连续。
6、非簇索引 非簇索引与物理顺序无关，设计它时必须有高度的可选择性，可以提高查询速度，但对表update的时候这些非簇索引会影响速度，且占用空间大，如果你愿意用空间和修改时间换取速度可以考虑。
7、索引视图 如果在视图上建立索引,那视图的结果集就会被存储起来，对与特定的查询性能可以提高很多，但同样对update语句时它也会严重减低性能，一般用在数据相对稳定的数据仓库中。
8、维护索引 你在将索引建好后，定期维护是很重要的，用dbcc showcontig来观察页密度、扫描密度等等，及时用dbcc indexdefrag来整理表或视图的索引,在必要的时候用dbcc dbreindex来重建索引可以受到良好的效果。 不论你是用几个表1、2、3点都可以提高一定的性能，5、6、8点你是必须做的，至于4、7点看你的需求，我个人是不建议的。打了半个多小时想是在写论文，希望对你有帮助。

Ⅱ 利用MySQL数据库如何解决大数据量存储问题

mysql解决大数据量存储问题的方法是分表。
1.如何去分表
根据什么策略把现有表中的数据分到多个表中，并且还有考虑到以后的扩展性上。

建立一张索引表，用户id与数据库id对应，（这里他将相同结构的表分在了不同的数据库中进一步减少压力，但同时对于数据的同步也需要通过其他手段来解决），其本质也是分表了同时分库了。这么做的好处是便于以后的扩展，但损耗一点性能，因为会多一次查询。这样索引表可能会成为新的瓶颈，除非用户不会一直增长哈。
我的做法属于另一种，写了个算法通过计算某列值，按照一定规律将数据大致均分在每个分表中。至于扩展性，写算法时候考虑进去了以后增加分表数的问题了。
选择哪种策略，是要看自己的表的业务特点了，方法没有绝对的优缺，还是要根据自己的需求选取。
2.分表之后主键的维护
分表之前，主键就是自动递增的bigint型。所以主键的格式已经提早被确定了，像什么uuid之类的就被直接pass掉了。
还有想过自己写一个主键生成程序，利用Java 的Atomic原子量特性，但是考虑还需要增加工作量并且高并发下，这里很可能是个隐患。
还有就是通过应用层上管理主键，如redis中有原子性的递增。

Ⅲ 怎样设计一个良好大数据处理的解决方案

在园子里面虽然待的时间不久，不过也有一年有余了，遇到了问题，第一个想到的就是去园子里面借鉴一些前辈们的经验，以免自己走弯路。渐渐的自己也有了一定的独立处理问题的能力，大神们不要喷我是标题党，标题是疑问，小弟不才，遇到了一些数据同步问题或是解决方案错误的麻烦，需要求助大神们，如果您不是赶时间，帮忙看完这篇文章，留上两句言就可以了，小弟不胜感激。好了，不多扯淡了，赶快说正事。1、项目介绍 下图为目前项目的整体框架图，大至如下：这是一个winform系统，采用了.NET Framework3.5和SQL Server2008编写与存储。这是一个某车辆监控管理系统，分为前端采集车辆信息，然后存储到后台数据库服务器上，整个系统的大致流程是：前端采集的图片数据，通过交换机统一接口，将数据传入到负责存储的中心服务软件（以下简称为“服务软件”），然后服务软件将接收到的数据存入到数据库中（数据库为SQLServer2008），客户端通过网络去访问数据库的信息，进行检索等一些操作。这是一个大至流程，上图中有N个分中心，每个点都部署了一样的系统及软件，流程一样，然后将分中心的数据同步到总的服务器上，主要同步的对象是从相机过来的照片（照片是转换为二进制后存储到数据库某表中的）及一些相关数据，实现总点可以查看各个分点的数据信息。2、目前问题 由于图片是存储在数据库表中的，由数据量过大，平均一天有20万左右的信息需要存储，峰值每秒达到了15-20条左右的记录，图片压缩后为150KB左右的高清图，服务器为24*365天工作的，所以压力比较大，目前的问题是服务器的磁盘IO出现了瓶颈（服务器采用了500G的硬盘做了磁盘阵列），服务器的连接通讯管道出现了拥堵，写入操作超时。这种情况偶尔会发生。3、个人的解决方案 经过研究发现，出现了该情况的最大问题在于服务器的磁盘IO出现了瓶颈，频繁的写操作，导致写入操作超时，于是我们就对证下药，解决磁盘IO的压力，由于之前图片是存储在数据库表中的，在占用了数据库的大量空间的同时又减慢了客户端访问服务器的速度。有些时候不是所有的事情软件都能解决的，我们对硬件进行一个升级，同时改变一下系统的存储策略，把图片单独存储，解决服务器的IO瓶颈，减轻服务器写操作的压力。 4、遇到的问题 上图的方案貌似是可以解决问题，但是问题来了，如果更好的把分中心的数据同步到总服务器上（主要指图片服务器），目前图片保存的格式是：年月日文件夹/相机IP文件夹/照片编号.JPG 如何在保证了可以快速的同步图片至总服务器的同时，又可以保证图片数据的完整性，不会在同步过程中出现丢失或其它问题，曾经考虑过利用数据库中记录图片的路径，远程访问图片信息，这样倒省去了同步图片的麻烦，可是效率过低，而且对网络要求过高；另外想到的一种方法就是利用FTP进行图片同步，自己写同步代码，定制同步机制。5、求助 求助各位大神们，有遇到过类似问题或是有这方面经验的，可以提一下自己的建议和看法，对于目前遇到的情况，不止是同步，包括这个解决方案的可行性给出一些意见和建议，在你们的不吝指教中，小弟或许会找到一些答案。 1、对上上述的方案，可否有更好的解决方案； 2、对于不同的方案，可否有更好的、详细的解决办法； 3、对于上述方案，关于存储和同步是否有更好的意见和建议； 小弟在这里感谢各们园子里面的兄弟姐妹了，希望你们踊跃发言，多一个人多一份力量，看到了就说上两句，留个言吧。小弟在线等留言，感谢了！

Ⅳ 如何从数据库调取数据形成大数据可视图化柱状图设计代码

1、excel表格里面直接插入“图表”，然后进行可视化图表设置，优点：比较方内便，直接插入；缺点：操作容相对复杂，数据量大的情况下excel超级慢；
2、将excel数据导入BDP个人版，然后直接拖拽字段后选择可视化图表类型即可；优点：操作简单、性能支持数据大的文件、图表类型多；缺点：要导入数据；
2种方式你都可以试试，自己评估下。。。
-

Ⅳ 如何设计企业级大数据分析平台

统企业的OLAP几乎都是基于关系型数据库，在面临“大数据”分析瓶颈，甚至实时数据分析的挑战时，在架构上如何应对?本文试拟出几个大数据OLAP平台的设计要点，意在抛砖引玉。
突破设计原则
建设企业的大数据管理平台(Big Data Management Platform)，第一个面临的挑战来自历史数据结构，以及企业现有的数据库设计人员的观念、原则。数据关系、ACID在关系数据库几十年的统治时期是久得人心，不少开发人员都有过为文档、图片设计数据表，或将文档、图片序列化为二进制文件存入关系数据库的经历。在BDMP之上，我们需要对多种不同的格式的数据进行混合存储，这就必须意识到曾经的原则已经不再适用——One size dosen’t fit all，新的原则——One size fits a bunch.
以下是我列出的一些NoSQL数据库在设计上的模式：
文档数据库：数据结构是类JSON，可以使用嵌入(Embed)或文档引用(Reference)的方式来为两个不同的文档对象建立关系;
列簇数据库：基于查询进行设计，有宽行(Wild Rows)和窄行(Skinny Rows)的设计决策;
索引数据库：基于搜索进行设计，在设计时需要考虑对对每个字段内容的处理(Analysis)。
搜索和查询的区别在于，对返回内容的排序，搜索引擎侧重于文本分析和关键字权重的处理上，而查询通常只是对数据进行单列或多列排序返回即可。
数据存储的二八原则
不少企业在解决海量数据存储的问题上，要么是把关系数据库全部往Hadoop上一导入，要么是把以前的非结构化数据如日志、点击流往NoSQL数据库中写入，但最后往往发现前者还是无法解决大数据分析的性能瓶颈，后者也无法回答数据如何发挥业务价值的问题。
在数据的价值和使用上，其实也存在着二八原则：
20%的数据发挥着80%的业务价值;
80%的数据请求只针对20%的数据。
目前来看，不管是数据存储处理、分析还是挖掘，最完整和成熟的生态圈还是基于关系型数据库，比如报表、联机分析等工具;另外就是数据分析人员更偏重于查询分析语言如SQL、R、Python数据分析包而不是编程语言。
企业大数据平台建设的二八原则是，将20%最有价值的数据——以结构化的形式存储在关系型数据库中供业务人员进行查询和分析;而将80%的数据——以非结构化、原始形式存储在相对廉价的Hadoop等平台上，供有一定数据挖掘技术的数据分析师或数据工程师进行下一步数据处理。经过加工的数据可以以数据集市或数据模型的形式存储在NoSQL数据库中，这也是后面要讲到的“离线”与“在线”数据。
理解企业的数据处理需求
数据库到数据仓库，是事务型数据到分析型数据的转变，分析型数据需要包括的是：分析的主题、数据的维度和层次，以及数据的历史变化等等。而对大数据平台来说，对分析的需求会更细，包括：
查询：快速响应组合条件查询、模糊查询、标签
搜索：包括对非结构化文档的搜索、返回结果的排序
统计：实时反映变化，如电商平台的在线销售订单与发货计算出的库存显示
挖掘：支持挖掘算法、机器学习的训练集
针对不同的数据处理需求，可能需要设计不同的数据存储，还需要考虑如何快速地将数据复制到对应的存储点并进行合适的结构转换，以供分析人员快速响应业务的需求。
离线数据与在线数据
根据不同的企业业务，对“离线”的定义其实不一样，在这里离线数据特指在业务场景中适用于“历史数据”的部分。常见的历史数据查询分析一般来自于特定时间段，设计上需要考虑的是将数据存入历史库中时，建立时间索引。另一种情况是某种业务问题的定位或分析，在数据量巨大的情况下，基于Hadoop或Spark等框架编写分析算法并直接在平台上运行，可以大大节约数据导出导入、格式转换与各种分析工具对接的时间。

在线数据处理按照存储和分析的先后顺序，可分为批处理(先存储后分析)和流处理(先分析后存储)两类。Cassandra数据库的设计采用上数据追加写入模式，可以支持实时批处理;流式计算平台则有Apache Storm、Yahoo S4等开源框架，商业平台有Amazon Kenisis(部署在云端)。企业的实时分析需求往往有特定的应用场景，需要对业务和现行系统有深入的理解才能设计出一个合理的架构。

Ⅵ 大数据数据库有哪些

分享10个超好用的数据库：
1、CouchDB
CouchDB是一款完全拥抱互联网的数据库，它将数据存储在文档中，这种文档可以通过Web浏览器来查询，并且用JavaScript来处理。它易于使用，在分布式上网络上具有高可用性和高扩展性。支持的操作系统：Windows、Linux、OS X和安卓。
2、Blazegraph
Blazegraph是一种高度扩展、高性能的数据库。它既有使用开源许可证的版本，也有使用商业许可证的版本。
3、Cassandra
Cassandra数据库最初由Facebook开发，现已被1500多家企业组织使用，它能支持超大规模集群；比如 说，苹果部署的Cassandra系统就包括75000多个节点，拥有的数据量超过10 PB。
4、FlockDB
FlockDB是一种非常快、扩展性非常好的图形数据库，擅长存储社交网络数据。虽然这个项目的开源版已有一段时间没有更新了，但它仍可用于下载。
5、Neo4j
Neo4j是速度快、扩展性佳的原生图形数据库，它具有大规模扩展性、快速的密码查询性能和经过改进的开发效率。支持的操作系统：Windows和Linux。
6、Pivotal Greenplum Database
Greenplum是同类中不错的企业级分析数据库，能够非常快速地对庞大的海量数据进行功能强大的分析。它是Pivotal大数据库套件的一部分。支持的操作系统：Windows、Linux和OS X。
7、Impala
Cloudera基于SQL的Impala数据库是面向Apache Hadoop的开源分析数据库。它可以作为一款独立产品来下载，又是Cloudera的商业大数据产品的一部分。支持的操作系统：Linux和OS X。
8、InfoBright社区版
InfoBright为数据分析而设计，这是一种面向列的数据库，具有很高的压缩比。InfoBright.com提供基于同一代码的收费产品，提供支持服务。支持的操作系统：Windows和Linux。
9、Hibari
这个基于Erlang的项目是一种分布式有序键值存储系统，有很强的一致性。它最初是由Gemini Mobile Technologies开发的，现在已被欧洲和亚洲的几家电信运营商所使用。支持的操作系统：与操作系统无关。
10、MongoDB
mongoDB的下载量已超过1000万人次，是一款极其受欢迎的NoSQL数据库。MongoDB.com上提供了企业版、支持、培训及相关产品和服务。支持的操作系统：Windows、Linux、OS X和Solaris。

Ⅶ 大数据量的数据库表设计技巧

大数据量的数据库表设计技巧
即使是一个非常简单的数据库应用系统，它的数据量增加到一定程度也会引起发一系列问题。如果在设计数据库的时候，就提前考虑这些问题，可以避免由于系统反映迟缓而引起的用户抱怨。
技巧1：尽量不要使用代码。比如性别这个字段常见的做法：1代表男，0代表女。这样的做法意味着每一次查询都需要关联代码表。
技巧2：历史数据中所有字段与业务表不要有依赖关系。如保存打印发票的时候，不要只保留单位代码，而应当把单位名称也保存下来。
技巧3：使用中间表。比如职工工资，可以把每一位职工工资的合计保存在一张中间表中，当职工某一工资项目发生变化的时候，同时对中间表的数据做相应更新。
技巧4：使用统计表。需要经常使用的统计数据，生成之后可以用专门的表来保存。
技巧5：分批保存历史数据。历史数据可以分段保存，比如2003年的历史数据保存在 《2003表名》中，而2004年的历史数据则保存在《2004表名》中。
技巧6：把不常用的数据从业务表中移到历史表。比如职工档案表，当某一职工离开公司以后，应该把他的职工档案表中的信息移动到《离职职工档案表》中。
1、经常查询的和不常用的分开几个表，也就是横向切分
2、把不同类型的分成几个表，纵向切分
3、常用联接的建索引
4、服务器放几个硬盘，把数据、日志、索引分盘存放，这样可以提高IO吞吐率
5、用优化器，优化你的查询
6、考虑冗余，这样可以减少连接
7、可以考虑建立统计表，就是实时生成总计表，这样可以避免每次查询都统计一次
8、用极量数据测试一下数据
速度，影响它的因数太多了，且数据量越大越明显。
1、存储将硬盘分成NTFS格式，NTFS比FAT32快，并看你的数据文件大小，1G以上你可以采用多数据库文件，这样可以将存取负载分散到多个物理硬盘或磁盘阵列上。
2、tempdbtempdb也应该被单独的物理硬盘或磁盘阵列上,建议放在RAID0上，这样它的性能最高,不要对它设置最大值让它自动增长
3、日志文件日志文件也应该和数据文件分开在不同的理硬盘或磁盘阵列上，这样也可以提高硬盘I/O性能。
4、分区视图就是将你的数据水平分割在集群服务器上，它适合大规模OLTP,SQL群集上，如果你数据库不是访问特别大不建议使用。
5、簇索引你的表一定有个簇索引，在使用簇索引查询的时候，区块查询是最快的，如用between，应为他是物理连续的，你应该尽量减少对它的updaet,应为这可以使它物理不连续。
6、非簇索引非簇索引与物理顺序无关，设计它时必须有高度的可选择性，可以提高查询速度，但对表update的时候这些非簇索引会影响速度，且占用空间大，如果你愿意用空间和修改时间换取速度可以考虑。
7、索引视图如果在视图上建立索引,那视图的结果集就会被存储起来，对与特定的查询性能可以提高很多，但同样对update语句时它也会严重减低性能，一般用在数据相对稳定的数据仓库中。
8、维护索引你在将索引建好后，定期维护是很重要的，用dbccshowcontig来观察页密度、扫描密度等等，及时用dbccindexdefrag来整理表或视图的索引,在必要的时候用dbccdbreindex来重建索引可以受到良好的效果。
不论你是用几个表1、2、3点都可以提高一定的性能，5、6、8点你是必须做的，至于4、7点看你的需求，我个人是不建议的。

Ⅷ 如何设计数据库 实现大数据分析

数据库开发工程师抄的日常工作是袭设计、开发数据库系统和数据库应用软件，因此与软件研发的过程一样，会覆盖需求、设计、编程和测试四个阶段：
需求：深入调研用户市场需求，认清项目的应用场景，解决的问题，性能指标等，需要与数据库系统使用方反复沟通，确定具体的需求。
设计：根据收集整理的需求文档设计数据库系统软件的模型和架构，划分模块分别进行概要和详细设计。
编程：按照模块分工和设计文档，进行编码和调试。
测试：将开发完成的数据库系统交给测试人员进行测试，主要使用的测试方法有黑盒测试、白盒测试、压力测试、性能测试等，测试全部通过后即可等待发布。