 上传我的文档
 下载
 收藏
精品课件，培训，咨询诊断，企业内训，策划方案，规划设计，全套ppt，可研报告，。。。。。。
精品资料，精心选取，精细编辑，精益求精。
 下载此文档
正在努力加载中...
医药物流配送中心药品三维装箱优化及其模拟
下载积分：398
内容提示：医药物流配送中心药品三维装箱优化及其模拟
文档格式：PDF|
浏览次数：5|
上传日期： 12:27:39|
文档星级：
该用户还上传了这些文档
医药物流配送中心药品三维装箱优化及其模拟
官方公共微信您所在位置： &
&nbsp&&nbsp&nbsp&&nbsp
_无线网络优化工程技术研究开发中心可行性研究报告.doc61页
本文档一共被下载：
次 ,您可全文免费在线阅读后下载本文档。
文档加载中...广告还剩秒
需要金币：200 &&
_无线网络优化工程技术研究开发中心可行性研究报告.doc
你可能关注的文档：
··········
··········
广州市工程技术研究开发中心
可行性报告
工程中心名称：广州市无线网络优化工程技术研究开发中心
研究开发方向：无线网络优化
所属领域：电子、通讯
申请单位（盖章）：广东省电信规划设计院有限公司广州华景路1号南方通信大厦510630
联系人： 曾涛1座机电话号码00
联系电话： 座机电话号码 传真：座机电话号码
主管部门：天河区科学技术局
编写日期：2010年月日整个网络的容量覆盖和质量之间的一种不确定性3G网络优化带来困难和挑战未来的网络是一个可以自组织的网络，现在无论是网络的组织，还是3GPP里面，都未来的网络可以进行自动配置、优化、操作维护，这是对未来网络的要求。在NGMN组织奖SON项目列为重要的项目之一，也是“863”计划信息技术领域主要专题之一。基于网络运行数据的GSM网络自动频率规划研究的建设带来业务收入通过可以为用户提供更，，。综合考虑，本工程达产期的年收入为： 100万元。基本数据
计算期（年）：10
建设期（年）：本工程新增人数（人）：年人均工资（万元）：6
年人均福利（万元）：0.84，为年人均工资的14%
折旧：按双倍余额折旧法，折旧年限为5年
修理费（万元）：为固定资产原值的6%
年人均低值易耗品（万元）：1.2
年业务费（万元）：占工资＋福利＋修理费＋低值易耗品＋经营管理费五项之和的20%
年人均经营管理费（万元）：1
开办费、培训费：固定资产投资的1.5%
其他财务费：经营费用（其他财务费除外）的0.20%
固定资产残存值：3%
固定资产投资（万元）：定额流动资金：固定资产原值的2.00%
本全部投资和自有资金的财务评价指标。其结果见下表：
财务静态投资回收期（年）
正在加载中，请稍后...君，已阅读到文档的结尾了呢~~
时间自动机模型检测具体反例的生成与图形化显示详细,生成,测试,模型检测,时间自动..
扫扫二维码，随身浏览文档
手机或平板扫扫即可继续访问
时间自动机模型检测具体反例的生成与图形化显示
举报该文档为侵权文档。
举报该文档含有违规或不良信息。
反馈该文档无法正常浏览。
举报该文档为重复文档。
推荐理由：
将文档分享至：
分享完整地址
文档地址：
粘贴到BBS或博客
flash地址：
支持嵌入FLASH地址的网站使用
html代码：
&embed src='/DocinViewer-4.swf' width='100%' height='600' type=application/x-shockwave-flash ALLOWFULLSCREEN='true' ALLOWSCRIPTACCESS='always'&&/embed&
450px*300px480px*400px650px*490px
支持嵌入HTML代码的网站使用
您的内容已经提交成功
您所提交的内容需要审核后才能发布，请您等待！
3秒自动关闭窗口您已经赞过此文了。
京都收纳箱：DBM的直截了当地实现
发表时间：浏览量：5377评论数：0挑错数：0
本文作者介绍了 京都收纳箱 的开发和运行过程。
作者是京都收纳箱，以及东京收纳箱的开发者。日本社区网站mixi的开发人员。
http://alpha.mixi.co.jp/blog/?author=3
on 1 月 13, 2010 in . 本人就是去酒吧时，一定会忘了把背包带回家的mikio。现在来介绍我们近两个月快速开发出来的的一个轻量级的数据库：Kyoto Cabinet。 & 开发的原因 & 是广受欢迎的轻量级的数据库，它作为DBM，具备不错的功能和性能。但是，在开发中还是确有一些不满意的地方。 简单地说，全部使用C语言开发，标准库（和zlib/bzip2）以外的功能全都是自己实现的，因此虽然容易优化，但造成维护的难度增加了。 & 因此，我去年10月左右有了这样的想法，就算性能多少有些差也能接受，能够让自己更方便地的开发和维护，并且提高它的可移植性。在考虑各种方案后，最终决定采用C++语言，利用STL技术开发。 & 特征 & KC沿袭了TC的基本设计，因此也具有以下优点。 & &&& * 内置process，没有网络通信开销。 &&& * 使用静态hash结构,高速并发性很高。 &&& * 小空间高效的数据库文件。 &&& * 分开使用On memory数据库和文件数据库。 &&& * 确保transaction的ACID属性。 &&& * 动态分块，抑制了数据库肥大化。 &&& * API简单和容易使用。 &&& * 酷的名字。 & 另一方面，KC在运行方面下了功夫，和TC相比有以下优点。 & &&& * 更为节省空间。 &&& * 更多高度并行。 &&& * 底层抽象化，可运行在非POSIX环境。 &&& * 深层次抽象化record操作。 &&& * 运行方面的小的改善。 & KC的性能确实低于TC，现状是不到TC的一半。然而，由于用户态应当是高并行的情况，如果操作系统和硬件的高度并行性提高的话，使用并行处理的情况下，整体吞吐量可能超过TC。 & 节省空间 & 在任何数据库，为了管理记录都要存储数据，在TC和KC中，就是record的前置head。为了提高数据库的空间效率，减小这种head是非常重要的。 & TC中，通常模式下需要14个字节，大模式下需要22个字节的head大小。 通常模式和大模式的区别是，寻址时使用 4字节还是使用8字节。 4个字节的话，是最大2 ^ 32 = 4GB的地址，default alignment 16字节的话，最大可以处理 64GB的字节的数据库。 8个字节的话，可以处理2 ^ 63 = 8EB的数据库。 & 考虑现在一般的计算环境，一方面，4字节寻址能力不足，另一方面不存在8EB的storage。因此，KC统一了模式，利用6个字节寻址。6个字节的话，最大可以处理2 ^ 48 = 256TB的数据。对 default alignment 8字节的情况，可以最多处理2PB的数据库。现在，作为1台数据库处理的大小已经足够了。另外，default alignment 提高到32768的话，可以达到TC的最大数据库的大小8EB。 & 把寻址宽度从4字节提升到6字节，以 解决日益恶化的空间使用效率。用来管理容量的区域里面，算上用来确定record的magic number，同时为了平衡二叉树计算需要的存储空间，压制在16字节。与TC的通常模式的14字节相比，略有增加，但是比大模式的22字节要少很多。 & KC和TC运用静态散列索引方法（桶阵列）加快record检索速度，为了在桶阵列的要素不足的情况下不显著降低速度，使用二叉查找树进行hash值冲突管理，以减少计算量。因为一台机器能处理的record上限是应该是可以预知的，如果仔细tunning的话，也可以说二叉查找树机制是不必要的。因此，对于有能力作tunning的人才，也准备了线性模式。使用线性LIST进行冲突管理，可以节约6字节的子地址。换句话说，如果您使用的线性模式， 和桶阵列的大小相比，具备了敏感的特点，并且head大小减少到10个字节。 & 此外，KC使用在数据库的大小是32GB的情况下，4字节寻址就足够了，可以使用小模式。同时使用线性模式和小模式的情况下，每个record的head有8个字节就够了。这些都是相对TC的优点。 & 高度并行 & KC和TC使用pthread（POSIX线程）包，处理多线程排他。例如：为了更新的数据库文件的大小这种元数据，按照使用mutex来lock、更新、解除lock的顺序执行。这种结构本身是不可避免的，为了更新一个变量mutex的锁定/解锁是非常低效的，有可能的话当然要使用更轻量级的方法。
因为从gcc4开始，支持调用i386的原子计算功能，所以决定使用它。当然，在非英特尔CPU环境下，或者非gcc编译器情况下，你必须运用spinlock来替代。 & 此外，以并发度为着眼点，检查了全部代码，即使是没有lock free的情况， critical section 内部lock后进行任何系统调用都不被允许。 &
与TC同样，为了解决这个问题：“虽然有因为pread/pwrite系统调用不具有明确的内部状态（文件位置），并发度高的说法，但是实际上会发生意料外的问题”，灵活使用了mmap。曾经想在KC中全部的文件I／O都由mmap来处理，但是因为各种情况被放弃，并最终结合了mmap和pread/pwrite来实现。
非POSIX环境的对策 & 对于TC，为了最优化而不断破坏了模块化原则，变成了单核心的结构，造成依赖POSIX的代码在其他操作系统中的重用成为几乎不可能。不过，因为假设TC主要是用在web服务的后端，Linux/FreeBSD/Solaris等对于动态分配设计得已经很好的系统上，这就不成为一个问题。并且不会使用在嵌入式系统，或者Windows桌面环境上。 & 同时，KC是一个假设会运行在嵌入系统或者Windows系统上的。因此，会有overhead的开销，依赖系统的一部分是完全模块化的，标准的C++03中没有定义的symbol没有在hash数据库上使用。主要使用把文件I/O抽象得到的文件类和把thread管理抽象得到的thread类来实现。 & Windows版本还没有着手，我想几个月内会发布它。因为简化了结构，打算开发纯Java的版本，甚至有把数据库转成RFC的想法，——想想而已。
抽象化操作record & 在设计KC时，“KVS是什么”，“DBM是什么”作为哲学研究过了。其结果是，KVS应当是声明了以下方法的接口。 & &&& * set：存储键/值对，用get能够得到它。 &&& * get：指定一个键来检索，得到对应的值。 &&& * remove：指定键，清除对应的键/值对。 &&& * open：恢复之前close的存储。 &&& * close：set或者remove时保存更新后的数据到存储设备。 & KVS的的“Key-Value”表示set/get/remove，“Store/Storage”表示open/close。此外，DBM和上述KVS的运行形态是一个，运行时符合以下条件。 & &&& * 文件存储：存储状态保存在文件系统中的文件里。 &&& * 内置的过程：无网络通信发生，仅函数调用这样的低overhead的方法调用。 & 这些是我们的定义，KC就是DBM，DBM就是KVS，KC就是KVS。“不分散的不能称为KVS”，或“不是ACID不能称为数据库”等定义也可以作出，TC和KC实际被称作什么，是用户随意指定。 & KVS接口的实现被认为是KC，并假设并行处理的情况，键值对的操作仅有set/get/remove是不够的。单线程顺序处理的场合，record的状态通过get得到，它的内容或者对于其他情况，如果set或者remove哪条record，对于键值对的任何操作都能实现。另一方面，在并行处理的场合，get处理和set/remove处理之间有可能别的thread修改了record的状态，因此排他控制成为必要了。因此，有以下两个主要的战略。 & &&& * lock/unlock方法定义：从锁定记录开始，做任何操作，最终unlock操作是应用程序的责任。 &&& * 所有的操作在library内定义：上述操作在libray侧一个一个地实现。 & 前者，library侧的实现简单的同时，应用程序侧能够自由设置是否作排他处理、粒度等，但是，实现变得复杂了，成为出现deadlock等bug的原因。后者具有相反的特性，应用程序侧不能自由发挥，但是library侧的维护变得非常困难。TC采用后者，putcat或addint或addboule等很多的方法都很费力地都实现了，对KC来说，这种困难稍微减少了。 & 现在让我们回顾一下KVS的定义。对于record的任何操作，按照“调查特定record的状态，对于它不管是否作更新操作，按照原子操作来执行”的方式来抽象。例如，这可以解释为如下各种操作。 & &&& * set：调查record的状态，不管状态如何，都用新值去更新。 &&& * get：调查record的状态，如果有record，返回值，保持原来的状态。 &&& * remove：调查record的状态，如果有record则删除，否则什么也不做。 &&& * increment：调查record的状态，如果有record则认为是编号，否则认为是0，增加给定值后，改写record的值。 &&& * append：调查record的状态，如果有record则追加值到它后面，否则认为是一个空字符串，用给定值改写record的值。 & 举例来说，在和键对应的record的空间里，引导应用程序的运行者自由读取和写入操作record的值,在这个限定空间执行原子操作。也就是说，作为KVS的设计来说，与操作的具体内容无关，重要的是保证原子性的范围。基于这样一种想法来定义KVS如下。 & &&& * 可以记录键对应的值的1次以上的变更历史。 &&&&&&&&& o open方法，恢复某时刻的内存快照 &&&&&&&&& o close方法，保存该时刻的内存快照 &&& * 可以原子地进行键对应的record的状态取得和更新 &&&&&&&&& o 如果给定的键对应的record存在，该record的值作为参数调用回调函数 &&&&&&&&& o 如果给定的键对应的record不存在，无参数调用回调函数 &&&&&&&&& o 如果回调函数有返回值，则存储到原始键对应的值中 & 具体的API & 下面看一下，上述的KVS接口在C++的API中的实现。 & class DB { & // レコードの空間を訪問する操作主体のクラス & class Visitor { & public: &&& // 訪問時、更新が必要ない（no operation）の場合に返す値 &&& static const char* const NOP; &&& // 訪問時、そのレコードを削除したい場合に返す値 &&& static const char* const REMOVE; &&& // 仮想デストラクタ &&& virtual ~Visitor() {} &&& // 既存のレコードを訪問した場合に呼ばれるコールバック関数 &&& virtual const char* visit_full(const char* kbuf, size_t ksiz, &&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& const char* vbuf, size_t vsiz, size_t* sp) = 0; &&& // 存在しないレコードを訪問した場合に呼ばれるコールバック関数 &&& virtual const char* visit_empty(const char* kbuf, size_t ksiz, size_t* sp) = 0; & }; & // 訪問者を受け入れる & bool accept(const char* kbuf, size_t ksiz, Visitor* visitor, bool writable); & // データベースを開く & bool open(std::string& path, int mode); & // データベースを閉じる & bool close(); }; & 上面是Kyoto Cabinet实际的接口。应用程序，通过open可以使用database object之后，定义实现DB::Visitor任意的类，把它作为参数传给database object的accept方法，最后关闭database object。从database中以hoge为键检索对应值的程序如下： &&
DB db.open("casket", DB::OREADER); class : public DB::Visitor { & virtual const char* visit_full(const char* kbuf, size_t ksiz, &&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& const char* vbuf, size_t vsiz, size_t* sp) { &&& cout && string(kbuf, ksiz) && " has " string(vbuf, vsiz) && &&& return NOP; & } & virtual const char* visit_empty(const char* kbuf, size_t ksiz) { &&& cout && string(kbuf, ksiz) && " is empty" && &&& return NOP; & } } db.accept("hoge", 4, &visitor, false); db.close(); & & 由于每次都实现Visitor有些麻烦，KC实际的DB类里面，在accept中内置了典型的操作：set/get/remove/append/increment。然而，record的操作必须通过accept来作，library内的实现非常简洁，易于维护。
详细请参照KC 的教程和API文档。
实现上的小改进 & KC的 hash 函数采用了。是TC采用的各个字节37倍hash函数，自然语言的单词作为键的时候也能获得好的效率，但是具有当int等二进制数作为键时的冲突率很高的弱点。TC被设计为主要的USE CASE是全文检索的倒排index，因此自然语言作为键时性能很好，但是KC更重视通用性，因为TC的设计难以进行二进制数值作为键的检索，所以决定采用MurMur。和MurMur具有相同特性的被舍弃的原因是，自然语言的处理是FNVhash更好，但是考虑到二进制数值处理的稳定性，还是选用了MurMur。但是，hash函数部分预想采用可替换的插件方式。 & TC中虽然决定了可以采用gzip或者bzip2进行数值压缩，因为使用bzip2的人的不多，而且没有安装libbz2-dev包的人很多的原因，不采用bzip2。但是，和TC一样，采用了插件的形式，可以使用任何压缩函数，除了可以使用bzip2外，LZO、LZSS、LZMA都可以使用。 & 有可能会发生使用特定的hash函数、压缩函数生成的database文件，使用相同组合的函数却不能打开DB Object的不兼容现象，为此也开发了checksum机制，以方便在事前发现不兼容的现象。 & TC中,为了横向检索全部record，采用了内部迭代器。内部迭代器的方法：始终保持database内部当前读取位置的信息，容易确保原子性，实现起来很容易，但是具有仅仅使用一个迭代器的弱点。KC中，支持内部和外部迭代器。外部迭代器的方法：保存当前读取位置的cursor object交给应用程序生成和管理。操作全部record时，有原子性要求则使用内部迭代器，多个thread并发scan时不需要原子性，则使用外部迭代器。 & 此外，因为KC在通过迭代器访问record时，也是通过accept方法执行的，能够根据Visitor处理任意的原子过程，因此迭代过程中能够轻松完成修改record。无论如何，虽然STL的std::map::iteretor也兼容这操作，但是因为太麻烦而放弃了。
结论 & Kyoto Cabinet是Tokyo Cabinet的后续产品，性能虽然差了些，但是功能、并发度、可维护性和可移植性都提高了。现在还是alpha版本，很难说质量很好，但是目前就这么使用也是可以的。 & 作为对FAQ中的问题：TC是不是要被放弃了，我的回答是没那回事。或许，TC的使用环境，还是继续使用TC。非POSIX兼容的环境（通常是Windows）中需要DBM的情况，使用KC。在这个意义上，说KC是TC的后代版本，不如说作为QDBM的后代，和TC是兄弟更合适。
来自无觅插件
还没有人赞过这篇文章
(C) 2015 yeeyan.org
公司全称：北京译言协力传媒科技有限公司
京ICP备号&&京公网安备99号}