BDB产品家族在生命科学的应用
大家好，
在今年上半年，我们国家推出了一项7,000亿人民币的医疗改革方案，针对我们IT业界可谓影响很大。近期，我也关注到国内从事生命科学、医疗卫生等方向的一些IT的大动作。我想，在此从嵌入式应用的方向，和大家分享我的一些体会和心得。
- 生命科学中应用
我们的观察：
- 发现一味新药通常历时8-12年，涉及到庞大的数据量(来自美国辉瑞的反馈：1,000,000种配比; 若干TB的数据量，1 TB约合2,000张CD光盘信息)
- 新药研究可以是跨多个组织的合作行为，彼此共享数据 – 全球各地的临床研究机构，风险合资公司等
- 监管机构要求对数据严格管理和控制
- 数据安全，访问控制，审计，保存，审批，变更，搜索，来自相关规定和标准作业程序的要求
- 而违规的代价非常高 – 想象一下三鹿奶粉？
- 需要经济且可靠的数据管理方式，贯穿于每一个步骤和阶段
- 需要简单易用的，自适应的软件；倾向于“本地化”数据管理方案
- 个性化功能实现也需要基于一套高可靠的数据管理软件之上
- 很多的分析仪器和不同分析技术不间断地产生数据
- 仪器产生的数据直接写到文件系统，从而容易产生错误和数据丢失
- 没有标准化的数据格式：每台仪器连着一台独立的计算机
- 搜索分散于这些独立仪器中的数据几乎是不可能的
- 越来越多的实验室笔记的电子化
BDB等嵌入式数据库引擎的可能使用场合：
- 替换文件系统
- 工作流引擎，及多系统共享数据
- 非结构化/半结构化的数据
- 各种不同的格式和需求 – XML, Java, 脚本, 文档, 图像等
- 脱机工作下的数据缓存(如实验室的电子记录，片剂及其他原始数据)
- “物化视图”各种来源的数据 – Materialized View, 数据缓存
- 器械本身需要数据管理 - 对比文件系统，具有更高的可靠性
- 强调软件安全和测试 - Berkeley DB发布版包括完整的测试套件，能够轻松地制定和执行您的测试
- 可移植性 - Berkeley DB 运行于几乎所有的嵌入式平台
- Berkeley DB和其他Oracle技术的无缝集成
举例子来说：
- 在你医疗分析仪器（光谱，色谱等），可以用BDB来存取数据，保证效率和容错。
- 在你的医疗影像仪器上和医生的门诊系统上，可以用BDB来缓存你的DICOM数据，和后端的Oracle 11g DICOM数据库集成。
- 在很多仪器上的配置、管理的信息 – 通常是XML格式的，可以用到BDB-XML。
- 在临床、基因科学等研究系统里，可以用BDB-JE 的DPL API来定义基因图片上的Object-Relationship的信息，建立高效的持久化和数据可视化方案。这方面，国外已经有在做了。
- 等等
- 医疗卫生方面的应用
我们的观察：
- 各个国家在此方面投入在GDP比重呈快速增长态势：以美国为例，1990年比重为11%，到2005到15%。
- 老龄化趋势：据估计，中国到2025，超过65岁的人口达1.85亿；比2002年大约要翻一倍
- 慢性病人群快速增加：肥胖、糖尿病、心脏病等
- 医疗信息呈现信息化、分散化、个性化趋势：各种信息化的诊断仪器、电子病历、个人守护仪器、个人健康传感器、远程医疗等等
BDB等嵌入式数据库引擎的可能使用场合：
- 诊断仪器上
- 个人健康感应仪器 和 与之链接的个人PDA上
- 医生的诊断系统
- 远程医疗系统
- 医疗数据按区域集中（按省、区等）的“云计算”系统中
- 等等
举例子来说：
- 对照上面，不用我说了吧？
Web2.0等技术成就了Facebook、Twitter等成功。面对下一个10年，当人们生活质量提高，对医疗卫生的服务也越来越高要求，个性化监控、诊疗和健康数据的de-centralization看来是个不可避免的趋势。你觉得呢？
写了这么多，希望能大家一些启示。欢迎反馈。
我是一名做GIS开发的工程师，我现在正在研究的是国土调查海量数据的存储和发布，这些全国范围内的国土数据（矢量、栅格、表格等）数据量大，数据标准各异，而我们想把他们历年的数据整合到一个可共享，可应用的大型空间数据库中，并且能够逐年更新。目前我们采用了ORACLE SPATIAL来存储和发布，可是在数据互操作方面始终不顺利。那么我个人想利用OGC统一的标准GML才存储和共享这些海量空间数据，但是NXD是一个还在发展的学科方向，希望我们多交流，本人也正在做这方面的博士论文。
@柳晓华
首先感谢你对我们Berkeley DB产品的关注. Berkeley DB是一个高性能的数据库产品簇（包括C语言实现的，叫BDB；纯Java语言实现的BDB-JE；针对XML的数据库 – BDB-XML）。所有3个产品都支持事务性(ACID)和并发读/写操作. 另外，Berkeley DB是非关系型的 – 即它支持任何的数据类型，原因是它对数据的存储是基于key/value 数据对，这也是Berkeley DB灵活性的一个体现. 值得注意的一点是, Berkeley DB并不支持SQL, 而是提供了简单易用的get/put API调用，从而将最大的灵活性提供给了程序员。
回到你的情况，如果你对这些大量GIS数据做高效的存储和管理，并且需要并发和共享操作，那么Berkeley DB将绝对能满足你的要求。而且，你提到“数据标准各异”，我们觉得Berkeley DB对数据存储的灵活性将是支持各种不同数据标准的一个优势。比如，Berkeley DB Java 版本 （BDB JE）提供了Direct Persistence Layer (DPL)。利用DPL，你可以十分方便地存储你自定义的各种java类（你可以为不同的国土数据定义不同的类），也可以十分方便地进行读增删改操作。
然而，如果你要对这些大量的GIS数据进行进一步的、较为专业的操作（例如基于空间的查询等等），由于Berkeley DB提供简单易用的API给程序员，从而所有这一切的功能都得以轻松实现。举例来说，你可以参考一个关于用BDB-JE 存取 spatial data的一个项目：
http://forums.oracle.com/forums/thread.jspa?forumID=273&threadID=955013
最后，你提到ORACLE SPATIAL“在数据互操作方面始终不顺利”，不知道能否具体说说呢？