文本存储,这是一个我以前很少去实施具体应用的领域。
何以会说起文本数据库,从上篇:秋色园QBlog技术原理解析:性能优化篇:读写分离与文本数据库(十八) 中,看出是出于应用,故而有几许冲动。
当然地,从上文中,可以看出:基本基于文本的简单的读写应用,轻轻地严格地一点地来说和“数据库”不太着边,境界不够。
我想象中“文本数据库”,再怎么简单,也得应该有以下几个的吧:
2 :有主键ID,不是GUID时,咋也得整个自增ID吧(大伙的应用习惯)。
3 :能添加,修改,删除数据。
4 :最好还能查询,排序,分页,至于分组可能要求高了点。
5 :再最好有并发控制。
回头再看秋色园 QBlog 当前的应用是:
2 :基于第1点,只能说是文本的读取应用,和“数据库”还扯不上关系。
故从以上目前的应用来说,完全达不到文本数据库应用的境界。
当然,有了基于文本的应用,故而顺理成章的对文本扩展出的“文本数据库”产生了些许兴趣与冲动也就很自然了。
于是,我上网搜了一下“文本数据库”,发现.net界几乎没有它的身影,倒是曾在php界大放过异采,这是为什么呢?
这是为什么呢?估计是为了以下内容:
用文本当数据库的基本优势:
非要解释,我只能这么说:大伙都存的磁盘,直接存肯定比数据库绕了一定的存储结构规则后存的快,当然越往后越复杂,就不好说了。
2 :存取操作简单:
不用啥ADO.NET,直接System.IO.File就可以搞定,多省事啊!
用文本当数据库的基本劣势:
2 :并发似乎不太好
3 :删除与修改不好操作
4 :要变身成“文本数据库”有好多要事要处理:
a:这自增加ID咋出来啊?
b:这要查询咋整啊?
c:这要排序咋整啊?
用文本数据库的基本适用的应用场景:
单个(表)文本数据量不大:10万条数据以下,10M大小以下(一次性加载到内存中操作,就成了内存数据库了,速度哗啦啦)。
2 :大型应用,以文本为辅数据库:
通过将一些数据库分散到零散的文本中,降低主数据库的压力。
3 :中型应用,以文本为主数据库:
这个不好说,说不好,不说好,需要有一定强力的技术阵容支持。
为了更好的发挥“文本数据库”的能动性,本人花了些时间对其进行了些许研究及思考,下面和大伙分享一下经验:
1:存储结构
2:数据插入
3:更新、删除
方式一:简单型 [这个其实挺好,因此从文本数据库的应用场景上看,基本要求并不是太高]
将整个表的重新输出json,再重写一次文本就可以了。
方式二:复杂型[这个是性能考虑的多一些,对于文本数据库追求的过些过了一点,因为如果太复杂,何不找其它数据库,用文本不就图个简单么]
这个比较痛苦,这里也给出一点个人的思路想法:
1 :定表结构时,必须定好每个字段的长度,这样就定出一行总的最大长度。
2 :写一行数据时,不够总长时,后面补空(好像通常是写入\0)。
3 :更新或删除时,根据行的(ID-1)*总长,定位到起始写的位置,然后改写一行即可,如果是删除则当行全写空(\0)。
这里其实就是空间换时间,而且数据删除时,文本大小也没变化,是不是有点像access呢?
针以上面方式二,这里给出点示例代码:
fs.Seek( 定位要写入的开始位置 , SeekOrigin.Current);
fs.Write(..写入内容...);
fs.Close();
4:自增ID咋出来
下面给出一个参考的示例代码:
/// 下一个自增加ID
/// </summary>
private int NextID
{
get
{
lock (lockNextIDobj)
{
if (maxID > 0 )
{
maxID ++ ;
}
else if (DataType.GetGroupID(Table.Columns[ 0 ].SqlType) == 1 ) // 自增ID仅对int有效
{
if (Table.Rows.Count > 0 )
{
int lastIndex = _Table.Rows.Count - 1 ;
do
{
if (lastIndex >= 0 )
{
if (_Table.Rows[lastIndex][ 0 ].IsNull)
{
lastIndex -- ;
}
else
{
maxID = Convert.ToInt32(_Table.Rows[lastIndex][ 0 ].Value) + 1 ;
}
}
else
{
maxID = 1 ;
}
}
while (maxID == 0 );
}
else
{
maxID = 1 ;
}
}
else
{
throw new Exception( " Increment id only use for int type " );
}
}
return maxID;
}
}
5:查询怎么办
6:排序怎么办
7:单进程并发怎么控制
8:多进程并发怎么控制
最后我想出来的方式是:进程在准备更改文本时,读取文本最后修改时间进行比对,进而达到一种相对控制。
总结:
个人觉得解决完上面的问题之后,基本简单的文本数据库也成型了,当然你也可以往上继续追求。
不过文本数据库,折腾的太复杂也没必要,毕竟文本数据库,还是以简单为主。
如果NoSql会流行,何不让文本数据库也在.net界也出出风头,成长成.Net界的一朵奇葩!