p**2
发帖数: 613 | 1 #1
有啥便宜好用一点的email marketing solution可以推荐？
自己搭也可以，有啥现成的轮子可以用？
现在在用cheetahmail，太贵，降低成本是第一目标。
#2
SQL数据库要怎么处理scalable？
我能想到的是丢RDS,分表，
根据数据tags不同分表，分服务器，
用NO-SQL做cache，还有啥方法？
#3
python这玩意实际项目开发大概什么个情况? |
f******2
发帖数: 2455 | 2
mailchimp在不在你考虑范围?
Google "sharding", "consistent hashing"; 然后每个shard用rds
非常好。不过听说java也不错。
【在 p**2 的大作中提到】
: #1
: 有啥便宜好用一点的email marketing solution可以推荐？
: 自己搭也可以，有啥现成的轮子可以用？
: 现在在用cheetahmail，太贵，降低成本是第一目标。
: #2
: SQL数据库要怎么处理scalable？
: 我能想到的是丢RDS,分表，
: 根据数据tags不同分表，分服务器，
: 用NO-SQL做cache，还有啥方法？
: #3
|
d******e
发帖数: 2265 | 3 email marking有啥要求和难度？
你要python的话，celery后台pool丢几个email server是标准解决方案，随便发多少都
可以。
sql 这个上网查查好了。
python蛮好，如果你对性能要求不高的，用户不多的话。
【在 p**2 的大作中提到】
: #1
: 有啥便宜好用一点的email marketing solution可以推荐？
: 自己搭也可以，有啥现成的轮子可以用？
: 现在在用cheetahmail，太贵，降低成本是第一目标。
: #2
: SQL数据库要怎么处理scalable？
: 我能想到的是丢RDS,分表，
: 根据数据tags不同分表，分服务器，
: 用NO-SQL做cache，还有啥方法？
: #3
|
w********m
发帖数: 1137 | 4 按stackoverflow的做法没错
SQL数据库处理scalable，
就是去买更牛逼的硬件。
一分钱，一分货。
什么shard，分表，分库都是哄人。
python现在是主流了吧
性能的话
都是用redis的数据结构
用天顶星的语言都差不多 |
p**2
发帖数: 613 | 5 #1
没啥具体要求难度，
就是每个月发110万左右的promotion邮件，
是我自己一个小客户，想降低一点email blast的cost
我比较懒，想直接找一个便宜点的公司把现在的换掉，
自己搞的也行，但是对客户来说，把我hours算上也不一定便宜。
#2
python能否展开说说，
性能不高具体项目里大概什么个情况，
用户不多，大概做多少级别的用户问题不大？
【在 d******e 的大作中提到】
: email marking有啥要求和难度？
: 你要python的话，celery后台pool丢几个email server是标准解决方案，随便发多少都
: 可以。
: sql 这个上网查查好了。
: python蛮好，如果你对性能要求不高的，用户不多的话。
|
p**2
发帖数: 613 | 6 多谢，分表分库还是有些提高的，就是sync的时候麻烦一些。
语言方面我用c#跑一样的data structure+loop，
c#基本都是100ms以上，java/c基本都是<10ms，
郁闷
【在 w********m 的大作中提到】
: 按stackoverflow的做法没错
: SQL数据库处理scalable，
: 就是去买更牛逼的硬件。
: 一分钱，一分货。
: 什么shard，分表，分库都是哄人。
: python现在是主流了吧
: 性能的话
: 都是用redis的数据结构
: 用天顶星的语言都差不多
|
w********m
发帖数: 1137 | 7 SQL是过度设计的典范。
什么都想在硬盘上实现，最后搞得一团糟。
各种各样的schema design，normalization，
提高了读的性能，写的性能自然降低。
反之依然。
到了最后只有拼硬件。
还有stored procedure，大毒瘤。不知道怎么维护才好。
search也一样，在硬盘上search要多慢有多慢。
还有什么BI啥的。
其实老老实实做个硬盘上的data store就完了。
stackoverflow的数据库做法就是今后的趋势。
四台数据库服务器。一个读，一个写，另外两个做备份。多了也没用。
【在 p**2 的大作中提到】
: 多谢，分表分库还是有些提高的，就是sync的时候麻烦一些。
: 语言方面我用c#跑一样的data structure+loop，
: c#基本都是100ms以上，java/c基本都是<10ms，
: 郁闷
|
p**2
发帖数: 613 | 8 有道理，写+读+备份
读的部分再捣鼓捣鼓，估计就差不多了。
【在 w********m 的大作中提到】
: SQL是过度设计的典范。
: 什么都想在硬盘上实现，最后搞得一团糟。
: 各种各样的schema design，normalization，
: 提高了读的性能，写的性能自然降低。
: 反之依然。
: 到了最后只有拼硬件。
: 还有stored procedure，大毒瘤。不知道怎么维护才好。
: search也一样，在硬盘上search要多慢有多慢。
: 还有什么BI啥的。
: 其实老老实实做个硬盘上的data store就完了。
|
