h******e
发帖数: 52 | 1 数据量不大的话，比如几十上百G，好像SQLprefereable 还是nonsql
另外要不要把 longURL->shortUrl 和shortUrl->LongURL都存下来？ |
T****U
发帖数: 3344 | 2 数据存储mysql应该就够了，但是如果访问量比较大的时候，峰值100/s以上那种，需要
用in mem database, 或者自己写个简单的k-v store cache data.
你有table了，long, short都在表里面，一般都是short url当主键，因为大部分访问
量都是short to long.
sql nosql主要问题是数据是否结构化，简单判断就是数据表是否过于复杂，查询时需
要join很多表 |
N*D
发帖数: 3641 | 3 Case by case. 需求不明，没法决定。
【在 h******e 的大作中提到】
: 数据量不大的话，比如几十上百G，好像SQLprefereable 还是nonsql
: 另外要不要把 longURL->shortUrl 和shortUrl->LongURL都存下来？
|
N*D
发帖数: 3641 | 4 100/s不是较大，是极小。。。
【在 T****U 的大作中提到】
: 数据存储mysql应该就够了，但是如果访问量比较大的时候，峰值100/s以上那种，需要
: 用in mem database, 或者自己写个简单的k-v store cache data.
: 你有table了，long, short都在表里面，一般都是short url当主键，因为大部分访问
: 量都是short to long.
: sql nosql主要问题是数据是否结构化，简单判断就是数据表是否过于复杂，查询时需
: 要join很多表
|
w**z
发帖数: 8232 | 5 一般 query, MySQL 几千 per second 毫无压力。
【在 N*D 的大作中提到】
: 100/s不是较大，是极小。。。
|
T****U
发帖数: 3344 | 6 几百G的数据量，你不放到内存，每次查硬盘还是不行把
http://northernmost.org/blog/mysql-query-cache-vs-memcached-rid
The MySQL query cache is invalidated as soon as the table is modified in any
shape or form. Be it an UPDATE, INSERT or DELETE.
这种频繁读写的数据，还是放到内存比较好，而且利于分布式设计，增加处理能力和冗
余。
【在 w**z 的大作中提到】
: 一般 query, MySQL 几千 per second 毫无压力。
|
N*D
发帖数: 3641 | 7 放内存还是放硬盘，交给storage layer决定，不是你app layer考虑的问题。
最后还是一句话：需求不明，没发设计。
数据量多大？1GB？1TB？1PB？
访问量多大？读多少？写多少？1 qps，还是100qps，还是100k qps，还是10m qps
Latency要求？1ms？10ms？100ms？1s？
然后use case：需要给短的读长的？需要给长的读短的？
然后各种细节：一个长的缩成固定的短的？同一个用户short一个长的consistently产
生一个短的？不同用户short一个长的产生几个短的？
等把问题弄清楚，面试就差不多结束了。
【在 T****U 的大作中提到】
: 几百G的数据量，你不放到内存，每次查硬盘还是不行把
: http://northernmost.org/blog/mysql-query-cache-vs-memcached-rid
: The MySQL query cache is invalidated as soon as the table is modified in any
: shape or form. Be it an UPDATE, INSERT or DELETE.
: 这种频繁读写的数据，还是放到内存比较好，而且利于分布式设计，增加处理能力和冗
: 余。
|
T****U
发帖数: 3344 | 8 那我们算算，就是基本的长生成短，短读取长的服务，1million dau, 10%的人用长变
短服务，每人每天3次请求，所有用户每人平均使用短到长服务5次，
峰值按10倍计算。
那么写操作是35qps,读操作是600qps
一天300M数据，一年是100G左右
怎么设计比较好？
【在 N*D 的大作中提到】
: 放内存还是放硬盘，交给storage layer决定，不是你app layer考虑的问题。
: 最后还是一句话：需求不明，没发设计。
: 数据量多大？1GB？1TB？1PB？
: 访问量多大？读多少？写多少？1 qps，还是100qps，还是100k qps，还是10m qps
: Latency要求？1ms？10ms？100ms？1s？
: 然后use case：需要给短的读长的？需要给长的读短的？
: 然后各种细节：一个长的缩成固定的短的？同一个用户short一个长的consistently产
: 生一个短的？不同用户short一个长的产生几个短的？
: 等把问题弄清楚，面试就差不多结束了。
|
N*D
发帖数: 3641 | 9 两个服务器 + 一个MySQL就行了，没latency要求的话连memcache都省了。
【在 T****U 的大作中提到】
: 那我们算算，就是基本的长生成短，短读取长的服务，1million dau, 10%的人用长变
: 短服务，每人每天3次请求，所有用户每人平均使用短到长服务5次，
: 峰值按10倍计算。
: 那么写操作是35qps,读操作是600qps
: 一天300M数据，一年是100G左右
: 怎么设计比较好？
|
N*D
发帖数: 3641 | 10 这是老黄历了，query cache写invalidate相关entries，这也是标准做法。
any
【在 T****U 的大作中提到】
: 几百G的数据量，你不放到内存，每次查硬盘还是不行把
: http://northernmost.org/blog/mysql-query-cache-vs-memcached-rid
: The MySQL query cache is invalidated as soon as the table is modified in any
: shape or form. Be it an UPDATE, INSERT or DELETE.
: 这种频繁读写的数据，还是放到内存比较好，而且利于分布式设计，增加处理能力和冗
: 余。
|
|
|
T****U
发帖数: 3344 | 11 这个latency指什么？
如果预计使用量增加10倍，到350qps写，6000qps读，数据到1T, 怎么设计好？
如何保证HA, 这时候要加memcache, mysql至少有1，2个backup把
【在 N*D 的大作中提到】
: 两个服务器 + 一个MySQL就行了，没latency要求的话连memcache都省了。
|
N*D
发帖数: 3641 | 12 6000个读吧？
用MySQL就要sharding了，假设每个MySQL能支持2K read，在保守点，4个sharding；每
个sharding 500GB，外加一个slave；
如果scale上去了，就用NoSQL，反正你也不需要relational的功能。如果需要短查长，又
需要长查短，NoSQL支持secondary index就好，不然就在App上dual write，不过要自
己做consistency，比较麻烦。
latency指读写速度。比如MySQL能搞几十个ms，上memcache能搞到几个ms而已。
【在 T****U 的大作中提到】
: 这个latency指什么？
: 如果预计使用量增加10倍，到350qps写，6000qps读，数据到1T, 怎么设计好？
: 如何保证HA, 这时候要加memcache, mysql至少有1，2个backup把
|
T****U
发帖数: 3344 | 13 6000读，如果用memcache，估计一两台机器做数据缓冲服务就够了，因为你不需要读入
所有数据，也就没必要做sharding了。后面mysql再搞一两个backup。
写服务也可以batch异步操作，那mysql的写也不是问题了。
长查短搞两个表在memcache就行了，mysql还是一个表，不需要同步。
【在 N*D 的大作中提到】
: 6000个读吧？
: 用MySQL就要sharding了，假设每个MySQL能支持2K read，在保守点，4个sharding；每
: 个sharding 500GB，外加一个slave；
: 如果scale上去了，就用NoSQL，反正你也不需要relational的功能。如果需要短查长，又
: 需要长查短，NoSQL支持secondary index就好，不然就在App上dual write，不过要自
: 己做consistency，比较麻烦。
: latency指读写速度。比如MySQL能搞几十个ms，上memcache能搞到几个ms而已。
|
N*D
发帖数: 3641 | 14 呵呵，假设你的DB是2k的capacity，你没法保证cache hit rate能上66%吧，连访问
pattern是啥都不知道的情况下。
而且Cache本身应该是functional optional的，如果你设计个系统，当辅助的cache
down了，你系统也down了的话，呵呵。
【在 T****U 的大作中提到】
: 6000读，如果用memcache，估计一两台机器做数据缓冲服务就够了，因为你不需要读入
: 所有数据，也就没必要做sharding了。后面mysql再搞一两个backup。
: 写服务也可以batch异步操作，那mysql的写也不是问题了。
: 长查短搞两个表在memcache就行了，mysql还是一个表，不需要同步。
|
T****U
发帖数: 3344 | 15 短链接服务主要是在twitter那种地方使用，高峰值通常是由于有热点事件，或者名人
发布链接导致，那么cache hit rate还是满高的，如果把memcache的有效时间设为1-2
天的，也就是几个G的内存量，那基本对mysql的访问量就是个平均值600。
memcache本身也是有冗余的，它如果也会挂，你的mysql+1slave也会有问题
【在 N*D 的大作中提到】
: 呵呵，假设你的DB是2k的capacity，你没法保证cache hit rate能上66%吧，连访问
: pattern是啥都不知道的情况下。
: 而且Cache本身应该是functional optional的，如果你设计个系统，当辅助的cache
: down了，你系统也down了的话，呵呵。
|
N*D
发帖数: 3641 | 16 Cache和Persistent data store从设计上cost, availability都不一样的。
2
【在 T****U 的大作中提到】
: 短链接服务主要是在twitter那种地方使用，高峰值通常是由于有热点事件，或者名人
: 发布链接导致，那么cache hit rate还是满高的，如果把memcache的有效时间设为1-2
: 天的，也就是几个G的内存量，那基本对mysql的访问量就是个平均值600。
: memcache本身也是有冗余的，它如果也会挂，你的mysql+1slave也会有问题
|
h******e
发帖数: 52 | 17 你这个算法有点问题吧？
1M - DAU，每人每天3次请求, 峰值按10倍， 应该是30M requests / (24*3600) = 347
qps in total, 34 write qps, 313 read qps
数巨量： 10% * 3M * (200bytes for long + short URL) / day => 60M / day
和你算的有出入呀？
【在 T****U 的大作中提到】
: 那我们算算，就是基本的长生成短，短读取长的服务，1million dau, 10%的人用长变
: 短服务，每人每天3次请求，所有用户每人平均使用短到长服务5次，
: 峰值按10倍计算。
: 那么写操作是35qps,读操作是600qps
: 一天300M数据，一年是100G左右
: 怎么设计比较好？
|
h******e
发帖数: 52 | 18 我的意见是选择no sql既然我们的query主要还是key value式的查询。大家觉得有什么
看法吗？
另外，我们应该选择short url做key吧。 当long url来的时候，我们经过算法转换到
short url。 如果key 已经存在就重复了。
【在 T****U 的大作中提到】
: 数据存储mysql应该就够了，但是如果访问量比较大的时候，峰值100/s以上那种，需要
: 用in mem database, 或者自己写个简单的k-v store cache data.
: 你有table了，long, short都在表里面，一般都是short url当主键，因为大部分访问
: 量都是short to long.
: sql nosql主要问题是数据是否结构化，简单判断就是数据表是否过于复杂，查询时需
: 要join很多表
|
x*********w
发帖数: 533 | 19
随便用个key value store不就可以了，随便部署在 2 ～ 3台服务器上，shard的
primary和secondary不要部署在一台机器上。。。。
这种应用也不用考虑transaction了，key value store各种cache，persisitency都有
支持，不用自己实现。
latency需求500ms以内纯属扯淡，需求不合理，拒绝实现
这有啥好考的，啥年代了还用memcache ＋ sql 吗 。。。
【在 h******e 的大作中提到】
: 数据量不大的话，比如几十上百G，好像SQLprefereable 还是nonsql
: 另外要不要把 longURL->shortUrl 和shortUrl->LongURL都存下来？
|
