- 主题:[小白求教]那些复杂的数据库在什么场景有价值呢
销售情况的揭示,资源揭示,资源管理,就是典型的在线分析呀。售票是典型的在线交易,他们必须同平台运行。这个系统就是oltp,OLAP混合系统。OLAP不能够影响oltp的运行。
这样的系统就需要大型的,复杂的商业数据库系统。
【 在 RuralHunter 的大作中提到: 】
: 你说的这些属于olap,但上面买票锁坐等就是oltp没有疑问。如果那些你要算olap那银行取钱要锁金额的也属于olap了
:
--
修改:ylh0315 FROM 221.218.60.*
FROM 221.218.60.*
属于有很强即席查询需求的OLTP
数据库实现大难点之一
【 在 RuralHunter 的大作中提到: 】
: 12306这都是oltp
--
FROM 222.70.23.*
无非是成本、性能、扩展性
【 在 LYMing1986 的大作中提到: 】
: 本人普通后端码农,日常用数据库时,感觉用到的数据库功能并不多,只需要快且稳定就够了。所以想问,那些复杂的数据库、数
:......
论坛助手,iPhone
--
FROM 112.64.68.*
不一样。进行结账显然属于olap。分日期车次,分线路,分席别数据汇总,典型的立方体剖面分析,就是OLAP。每个查询都要涉及大量数据,如果锁表,那么,查询期间,大量的车次的票都不能卖了,卡住了。
【 在 RuralHunter 的大作中提到: 】
: 你说的这些属于olap,但上面买票锁坐等就是oltp没有疑问。如果那些你要算olap那银行取钱要锁金额的也属于olap了
:
--
FROM 221.218.60.*
是。
难度在于,不能把一个席位卖给多人,也不能抢丢了,谁也没买着。
与股票不同,抢某一只股票,不会在意哪一张,大数不差就行。银行也不在意那钱的具体号码。
【 在 oldwatch 的大作中提到: 】
: 属于有很强即席查询需求的OLTP
: 数据库实现大难点之一
:
--
修改:ylh0315 FROM 221.218.60.*
FROM 221.218.60.*
结账是银行根据12306发过来的交易指令来进行的,在银行自己的数据库里
对账也只看日期和交易流水号,不需要车次线路信息
【 在 ylh0315 的大作中提到: 】
: 不一样。进行结账显然属于olap。分日期车次,分线路,分席别数据汇总,典型的立方体剖面分析,就是OLAP。每个查询都要涉及大量数据,如果锁表,那么,查询期间,大量的车次的票都不能卖了,卡住了。
--
FROM 114.253.38.*
我没说银行那边。就是票务系统这边,也得先自己结了,才能与银行对账清算。
【 在 roy 的大作中提到: 】
: 结账是银行根据12306发过来的交易指令来进行的,在银行自己的数据库里
: 对账也只看日期和交易流水号,不需要车次线路信息
:
--
FROM 221.218.60.*
我不知道12306是怎么设计和实现的
但我不觉得12306涉及的查询有多大
【 在 ylh0315 的大作中提到: 】
: 不一样。进行结账显然属于olap。分日期车次,分线路,分席别数据汇总,典型的立方体剖面分析,就是OLAP。每个查询都要涉及大量数据,如果锁表,那么,查询期间,大量的车次的票都不能卖了,卡住了。
--
FROM 167.220.233.*
一般来说,售票系统、财务系统是分开的
在设计上就应该用transaction保证这两个系统的记录是一致的,这是典型的OLTP应用场景。对不对账其实意义不大。
对账的时候按每个账户的总数核对就行,车次什么的没必要。
对账/盘点也不需要天天做,实时做。每周/每月找一天在没人的下半夜做一次就行
【 在 ylh0315 的大作中提到: 】
: 我没说银行那边。就是票务系统这边,也得先自己结了,才能与银行对账清算。
--
修改:roy FROM 114.253.38.*
FROM 114.253.38.*
12306设计的并不是太好,当初的数据库没选好。现在它需要限制查询量,在高峰期禁止一些部门任意查询。
【 在 mango7788 的大作中提到: 】
: 我不知道12306是怎么设计和实现的
: 但我不觉得12306涉及的查询有多大
--
FROM 221.218.60.*