技术头条 - 一个快速在微博传播文章的方式     搜索本站
您现在的位置首页 --> 查看专题: 数据库
    当使用Pytohn的 Flask-SQLAlchemy库操作 MySQL 数据时,出现'MySQL server has gone away' 了,是怎么回事呢?又该怎么办呢?分别从MySQL服务端和Python客户端来排查相关问题。
    按照重要程度划分数据库级别
    在说图数据库之前需要先了解下什么是图。形式上,图是点和边的组合;术语上,图是「一些节点」和「关联这些节点的联系」的组合。图广泛存在于世界之中,从人与人之间的联系、工厂与消费者之间的联系到电话与数据中心网络节点之间的关系、基因和蛋白质之间的关联,都会涉及大量的高度关联数据。这些数据构成了庞大的图,图数据库就是呈现和查询这些关联的做好的方式。
    首先看看这个榜单,2015年6月份最新的数据库流行度的前10名,它们分别是Oracle, MySQL, SQL Server, PostgresSQL, MongoDB, DB2, Microsoft Access, Cassandra, SQLite, Redis. 比较惊讶的是微软的Access。。。
    数据库客户端有着各种类型和大小。一些用起来不太爽,一些相当有爱。不幸的是,我已经发现所有的数据库客户端在不同的地方存在欠缺。下面是我认为的理想数据库客户端的特点。
    数据库从最早的打孔的方式记录数据,发展到网状数据库,且网状数据库应用较成熟与普遍,网状数据库也有其不能表达的数据关系,为此后来提出了层状数据库的理论,并且有相应产品的成功与应用,不过应用时间不长,业务应用范围不广泛,随机被关系数据库的理论所淹没而取代,关系数据库理论的基础之后数据库领域提出面向对象数据库和面对像关系混合型数据库的理论,并且也有相应产品的成功研发和应用,不过并没有像预测的那样,2010年将是面向对象数据库出现质飞跃的时间点。
    本文是对《big data glossary》第三章MapReduce的个人翻译,无版权 在传统的关系数据库世界中,所有的处理都发生在信息被载入存储之后,使用特定的查询语言处理高度结构化和优化的数据结构。而由Google引领,然后被许多其他网络公司所接纳的替代方式是:创建一个读写任意格式文件的流水线,在每个阶段以文件的方式交换中间结果,并且跨机器分布计算。通常基于MapReduce方法进行分布式工作的方法都需要一套全新的工具,我将在下面介绍。 Hadoop 最初是由Yahoo!开发的一套Google MapReduce架构的克隆系统,但随后被开源。Hadoop帮助你的代码在跨机器的集群上运行。它负责对输入的数据分块,并发送到各自对应的机器,在每个分块上运行代码,监测运行的代码,将结果发送到下一步的处理阶段或者最终存储下来,执行发生在map和reduce阶段间的排序工作并将排序后的数据发送到
    以下是偶参照各方资料写的一点数据库开发规范。 写的不是很全,而且一直在完善中,杯具的是发现和word写出来的格式上稍微有一点不一样的,嘿嘿,那就凑合看了。 欢迎讨论这个文档的内容,如果转载,请写明出处。 本规范采用以下术语描述: ★规则:也称为强规范是编程时必须强制遵守的原则 ★建议:编程时必须加以考虑的原则 ★说明:对此规则或建议进行必要的解释 ★示例:对此规则或建议从正、反两个方面给出 规则1: 数据库代码...
    1 hbase简介 2 hbase逻辑视图 3 hbase物理存储 4 hbase系统架构 5 hbase关键流程和算法 6 hbase接口结语
    随着数据存储技术的迅猛发展,随着各种 NoSQL 技术的产生,无论是我们同事之间还是整个互联网行业,都出现关于“分布式 数据 存储/处理 解决方案”方面的选择分歧。就我目前所了解到的主流意见主要有以下三种: 去关系型,NoSQL是王道 NoSQL靠边站,关系型才是王道以关系型为核心,NoSQL为补充 三种意见中前面两种观点较为极端,都是“非对即错”的选择,当然也有更为理性的第三种方案。如果作为开发人员,从我目前所了解的信...
    SSD作为flashcache与memcache作为数据库外部cache的最大区别在于,SSD掉电后数据是不丢失的,这也引起了另外一个思考,当数据库发生故障重启后,flashcache中的数据是有效还是无效?如果是有效的,那么就必须时刻保证flashcache中数据的一致性,如果是无效的,那么flashcache同样面临一个预热的问题(这与memcache掉电后的问题一样)。目前,据我所知,基本上都认为是无效的,因为要保持flashcache中数据的一致性,非常困难。
    

Kyoto Tycoon 是一个轻量级的数据库服务器, 支持自动过期的实现,这个在各种需要处理缓存数据的程序中很有用。Kyoto Tycoon 也是一个叫Kyoto cabinet的DBM的网络接口。虽然这个DBM拥有很高的性能和并发能力,但是你在处理多进程共享一个数据库,或是需要远程访问一个数据库时感到头痛。而Kyoto Tycoon就是提供来处理Kyoto cabinet的并发处理和远程连接的。Kyoto tycoon由管理各种各样数据库的服务器进程和访问服务器的客户端程序库组成。

    在WEB开发中,数据库的数据读写和传输一向是瓶颈,在此基础上的解决方案基本都是数据库连接层的设计,一个公司数据库连接层的牛B与否可以标识这个公司的全局规划的“工艺水平”到达一个什么样了。下面的内容来自明查暗访,决无BS之意,旨在提供给需要统一规划整体架构的架构师一个帮助。 54chen声明:本文所有内容本着技术分享的原则,收集资料皆来自网络,绝不透露不该透露的内容,绝不隐藏不该隐藏...
    Oren Eini(又名Ayende Rahien)建议开发者尽量避免数据库的软删除操作,读者可能因此认为硬删除是合理的选择。作为对Ayende文章的回应,Udi Dahan强烈建议完全避免数据删除。所谓软删除主张在表中增加一个IsDeleted列以保持数据完整。如果某一行设置了IsDeleted标志列,那么这一行就被认为是已删除的。 Ayende觉得这种方法“简单、容易理解、容易实现、容易沟通”,但“往往是错的”
    随着互联网web2.0网站的兴起,非关系型的数据库现在成了一个极其热门的新领域,非关系数据库产品的发展非常迅速。而传统的关系数据库在应付web2.0网站,特别是超大规模和高并发的SNS类型的web2.0纯动态网站已经显得力不从心,暴露了很多难以克服的问题,例如:1、High performance - 对数据库高并发读写的需求web2.0网站要根据用户个性化信息来实时生成动态页面和提供动态信息,所以...
[ 共15篇文章 ][ 第1页/共1页 ][ 1 ]
赞助商广告
© 2009 - 2024 by blogread.cn 微博:@IT技术博客大学习

京ICP备15002552号-1