关于db110数据库博客写作

2016年6月5日 205 views 没有评论

1、现在很难抽出时间来写博客,db110已经写了许多年,数据库的技术也已经很成熟了,也不需要我在博客里一直强调。也许是时间,慢慢放弃博客写作,或者减少更新的频率了。

2、最近几年,已经很少研究新的技术了,一方面是旧有的技术已经够用,一方面是自己的研究方向也有变化了。

3、未来会花更多时间在其他的领域,人应该不断接受新的挑战才是。

4、知乎里,facebook,linkedin,google+里都发了一些文章,其实都可以集中到自己的博客上来。简单更好。

 

 

分类: 职业生涯 标签:

关于Systems Performance: Enterprise and the Cloud

2016年5月24日 253 views 没有评论

1、这本书值得推荐看,也许因为作者行文还不够有趣,我只看了一遍,但知识含量是足的,Kindle上我也做了不少笔记。

2、今天把它加入了参考书目,毕竟我摘录了一些内容。

3、到网上搜了下,竟然2015年10月就有人翻译出来了。这样的书,一个人是很难以翻译出来的,毕竟都是些有工作的人。Amazon上的评论大概看了下,说有部分错误,但是翻译这么一本书,错误还真难免。你说要用心把,说句实话,作者/译者得到的回报可能很难以让人有毅力花费大量时间仔细校对。这个世界上,对于读者和作者都不要太苛求,无论在哪里,写书或者翻译书,更多是交流的手段而不是赚钱的方式,,错误是难免的,理解对了就好。

分类: 读书 标签:

MySQL DBA的职责

2016年5月9日 268 views 没有评论

MySQL DBA的职责
我列举一些DBA的工作职责,
维护线上数据库,保障安全、可靠、高性能。
部署上线新的业务的数据库
性能调优以及扩容计划
培训研发、测试团队
故障处理以及恢复数据
协助日常业务升级,升级数据库
升级MySQL版本
研究新技术、产品,评估新技术、产品
审核研发人员的数据库表设计,必要的时候参与数据库表设计
建设数据库的运维平台,自动化或者半自动化工作

分类: 数据库 标签:

XFS文件系统

2016年5月8日 284 views 没有评论

我们推荐在Linux下使用XFS文件系统,它是一种高性能的日志文件系统,特别擅长处理大文件,对比ext3、ext4,MySQL在XFS上一般有更好的性能,更高的吞吐。Red Hat Enterprise Linux 7默认使用XFS文件系统。Red Hat Enterprise Linux 5、6的内核完整支持XFS,但未包含创建和使用XFS的命令行工具,你需要自行安装。

如下是一个安装示例

下载xfsprogs包,并解压

./configure

make

make instal

which mkfs.xfs 确认已经安装好了创建xfs文件系统的命令。

安装了xfs后,我们就可以使用mkfs.xfs创建xfs文件系统,如下面的命令在/dev/sdb1上创建xfs文件系统

mkfs.xfs -f -d agcount=6 -l size=64m -i size=512 -L /home1 /dev/sdb1

部分参数解释:

-f 强制创建文件系统,即使已经存在旧的文件系统

-d选项。主要用于数据部份的参数指定。例如在一个raid设备中如何进行分配。

agcount 分配组的数量,XFS文件系统内部被分为多个“分配组”。 每个分配组各自管理自己的inode和剩余空间。可以设置为4、6、8等较小的值。

如果在raid阵列上创建xfs文件系统,你需要留意su、sw这两个参数的设置。你要根据RAID配置来设置这两个参数,su=value 可设置为raid的条带大小,sw=value  设置为独立的设备大小, 比如对于raid1+0 独立的设备为总的磁盘数量除以2 , 对于raid5,独立设备数为总的磁盘数量减1。如,-d su=128k,sw=3 。

分类: 操作系统, 数据库 标签:

pt-query-digest的使用

2016年5月7日 273 views 没有评论

pt-query-digest是最应该掌握的一个工具。它可以分析MySQL的各种日志,如慢查询日志、generel日志,也可以分析show processlist的输出。配合tcpdump我们还可以对线上数据库流量进行采样,实时监控数据库流量,及时发现性能问题。

基本用法如下,

pt-query-digest /path/to/slow.log > /path/to/keep/report_file

如果你有大量的数据库节点,可以考虑把pt-query-digest的分析报告写入数据库,方便检索和绘图。

输出的报表类似如下,以下截取了报告的部分内容,

# Overall: 565 total, 22 unique, 0.00 QPS, 0.00x concurrency _____________

# Time range: 2012-09-22 18:33:43 to 2012-10-16 10:45:31

# Attribute          total     min     max     avg     95%  stddev  median

# ============     ======= ======= ======= ======= ======= ======= =======

# Exec time          1233s   503ms     15s      2s      7s      2s      1s

# Lock time           53ms    31us   145us    94us   119us    17us    93us

# Rows sent          1.67k       0      20    3.02    9.83    4.12    0.99

# Rows examine     616.77M  72.90k  12.03M   1.09M   6.61M   2.02M 245.21k

# Query size       139.49k      25     381  252.81  346.17   70.94  234.30

 

# Profile

# Rank Query ID           Response time  Calls R/Call  Apdx V/M   Item

# ==== ================== ============== ===== ======= ==== ===== ========

#    1 0xBE5D289C750F172A 308.6929 25.0%    40  7.7173 0.00  0.08 SELECT ccc tbl_eee tbl_ddd bbb

#    2 0x5C898C5E065DD204 149.4144 12.1%   105  1.4230 0.50  0.00 SELECT tbl_ddd_info tbl_eee tbl_ddd

#    3 0x6F05415421300718 136.7381 11.1%    97  1.4097 0.50  0.00 SELECT tbl_ddd_info tbl_eee tbl_ddd

#    4 0x2E9AE41A4D2149A1 123.0681 10.0%    22  5.5940 0.00  0.02 SELECT ccc tbl_eee tbl_ddd bbb

#    5 0xAFF556BC27138443 121.9603  9.9%    73  1.6707 0.50  0.00 SELECT tbl_ddd_info tbl_eee tbl_ddd

#    6 0xD07F224EF598BD9A 105.0456  8.5%    16  6.5653 0.00  0.23 SELECT ccc tbl_eee tbl_ddd bbb

#    7 0xC22F9709F846BB4E  99.1936  8.0%    73  1.3588 0.50  0.00 SELECT tbl_ddd_info tbl_eee tbl_ddd

#    8 0x4CAD792BF4A54CE9  53.7477  4.4%     4 13.4369 0.00  0.17 SELECT tbl_fff tbl_eee tbl_ddd

#    9 0x347319A37AC29893  39.1390  3.2%    69  0.5672 1.00  0.00 SELECT tbl_fff pt_game_base_score

#   10 0x7EF77B274F1C37D3  27.2826  2.2%     4  6.8207 0.00  0.00 SELECT ccc tbl_eee tbl_ddd bbb

#   11 0x8383B2CB219358F3  16.7553  1.4%    18  0.9308 0.97  0.00 SELECT tbl_iii tbl_hhh tbl_eee

 

# MISC 0xMISC              51.5793  4.2%    44  1.1723   NS   0.0 <11 ITEMS>

 

# Query 1: 0.00 QPS, 0.00x concurrency, ID 0xBE5D289C750F172A at byte 120071

# This item is included in the report because it matches –limit.

# Scores: Apdex = 0.00 [1.0]*, V/M = 0.08

# Query_time sparkline: |      ^_|

# Time range: 2012-09-25 11:01:09 to 2012-10-16 10:14:31

# Attribute    pct   total     min     max     avg     95%  stddev  median

# ============ === ======= ======= ======= ======= ======= ======= =======

# Count          7      40

# Exec time     25    309s      7s     10s      8s      9s   802ms      7s

# Lock time      6     4ms    59us   110us    89us   103us [……]

Read more

分类: 数据库 标签: ,

阿姆达尔定律(Amdahl’s Law)

2016年5月6日 297 views 没有评论

阿姆达尔定律是一个计算机科学界的经验法则,因IBM公司计算机架构师吉恩·阿姆达尔而得名。吉恩·阿姆达尔在1967年发表的论文中提出了这个重要定律。

阿姆达尔定律主要用于发现仅仅系统的部分得到改进,整体系统可以得到的最大期望改进。它经常用于并行计算领域,用来预测适用多个处理器时理论上的最大加速比。在我们的性能调优领域,我们利用此定律有助于我们解决或者缓解性能瓶颈问题

阿姆达尔定律的模型阐释了我们现实生产中串行资源争用时候的现象。如下图模型,一个系统中,不可避免有一些资源必须串行访问,这限制了我们的加速比,即使我们增加了并发数(横轴),但取得效果并不理想,难以获得线性扩展能力(图中直线)。

 

1

以下介绍中、系统、算法、程序可以认为都是优化的对象,我不加以区分,它们都有串行的部分和可以并行的部分。

在并行计算中,使用多个处理器的程序的加速比受限制于程序串行部分的执行时间。例如,如果一个程序使用一个CPU核执行需要20小时,其中部分代码只能串行,需要执行1个小时,其他19小时的代码执行可以并行,那么,不考虑有多少CPU可用来并行执行程序,最小执行时间不会小于1小时(串行工作的部分),因此加速比被限制为最多20倍(20/1)。

加速比越高,证明优化效果越明显。

阿姆达尔定律可以用如下公式表示:

 

2

s( n ) 固定负载下,理论上的加速比。

B 串行工作部分所占比例,取值0~1,

n 并行线程数、并行处理节点个数

以上公式说明:

加速比=没有改进前的算法耗时/改进后的算法耗时。

如果我们假定算法没有改进之前,执行总时间是1(假定为1个单元)。那么改进后的算法,其时间应该是串行工作部分的耗时(B)加上并行部分的耗时(1-B)/n,由于并行部分可以在多个cpu核上执行,所以并行部分实际的执行时间是(1-B)/n

根据这个公式,如果并行线程数(我们可以理解为CPU处理器数量)趋于无穷,那么加速比与系统的串行工作部分的比例成反比,如果系统中有50%的代码串行执行,那么系统的最大加速比为2。也就是说,为了提高系统的速度,仅增加CPU处理器的数量不一定能起到有效的作用,需要提高系统内可并行化的模块比重,在此基础上合理增加并行处理器数量,才能以最小的投入得到最大的加速比。

 

我们对阿姆达尔定律做进一步说明。阿姆达尔这个模型 定义了固定负载下,某个算法的并行实现相对串行实现的加速比。例如,某个算法有12%的操作是可以并行执行的,而剩下的88%的操作不能并行,那么阿姆达尔定律声明,最大加速比是1(1-0.12)=1.136。如上公式n趋向于无穷大,那么加速比S=1/B=1/(1-0.12)。

再例如,对于某个算法,可以并行的比例是P,这部分并行的代码能够加速s倍(s可以理解是CPU核的个数,即新代码的执行时间为原来执行时间的1/s)。此算法30%的代码可以被并行加速,那么P等于0.3,这部分代码可以被加速2倍,s等于2。那么,使用阿姆达尔定律计算其整个算法的加速比:

3

以上公式和前一个公式类似,只是前一个公式的分母用串行比例B来表示。

再例如,某项任务,我们可以分解为4个步骤,P1、P2、P3、P4,执行耗时占总耗时百分比分别是11%、18%、23%、48%。我们对它进行优化,P1不能优化,P2可以加速5倍,P3可以加速20倍,P4可以加速1.6倍。那么改进后的执行时间是:

4

总的加速比是 1 / 0.4575 = 2.186 。我们可以看到,虽然有些部分加速比有20倍,5倍,但总的加速比并不高,略大于2,因为占时间比例最大的P4部分仅仅加速了1.6倍。

 

对于如下的图,我们可以观察到,加速比受限制于串行工作部分的比例,当95%的代码都可以进行并行优化时,理论的最大大加速比会更高,但最高不会超过20倍。

5

阿姆达尔定律也用于指导CPU的可扩展设计。CPU的发展有两个方向,更快的CPU或者更多的核。目前看来发展的重心偏向了CPU的核数,随着技术的不断发展,CPU的核数不断增加,目前我们的数据库服务器四核、六核已经比较常见,但有时我们会发现虽然拥有更多的核,当我们同时运行几个程序时,只有少数几个线程处于工作中,其它的并未做什么工作,实践当中,并行运行多个线程往往并不能显著提升性能,程序往往并不能有效的利用多核。在多核处理器中加速比是衡量并行程序性能的一个重要参数,能否有效降低串行计算部分的比例和降低交互开销决定了能否充分发挥多核的性能,其中的关键在于:合理划分任务、减少核间通信。

 

恢复独立表空间的表

2016年5月3日 310 views 没有评论

如果你有.ibd文件的一个干净的备份,你可以按如下操作从被起源的地方恢复它到MySQL安装中:

  1. 发出这个ALTER TABLE语句:

2. ALTER TABLE tbl_name DISCARD TABLESPACE;

警告:这个语句删除当前.ibd文件。

  1. 把备份的.ibd文件放回到恰当的数据库目录。
  2. 发出这个ALTER TABLE语句:

5. ALTER TABLE tbl_name IMPORT TABLESPACE;

在上下文中,一个.ibd文件干净的备份意为:

ibd文件里没有尚未提交的事务做的修改。

.ibd文件里无未合并的插入混充条目。

净化已经从.ibd文件移除所有已标注删除的索引记录。

mysqld已经把.ibd文件的所有已修改页面从缓冲池刷新到文件。

你可以用下列方法生成一个.ibd文件的干净备份:

  1. 停止所有来自mysqld服务器的活动,并提交所有事务。
  2. 等待直至SHOW INNODB STATUS显示在数据库被已经没有激活的事务,并且InnoDB主线程的状态是Waiting for server activity。然后你就可以复制.ibd文件了。

生成一个.ibd文件的干净复制的另一个方法是使用商业的InnoDB热备份工具:

  1. 使用InnoDB热备份工具备份InnoDB安装。
  2. 在备份上启动第二个mysqld服务器,让它清洁备份里的.ibd文件。
分类: 数据库 标签:

优化有BLOB,TEXT类型字段的查询

2016年4月29日 298 views 没有评论

由于MySQL的内存临时表不支持blob,text值,如果包含blob(text)列的查询需要用到临时表,就会使用基于磁盘的临时表,性能将急剧降低。所以编写查询语句,如果没有必要包含blob、text列,就不要也写入查询条件。

可以规避的办法有2种:

q  1.使用SUBSTRING( ) 函数。

q  2. 把临时表存放在基于内存的文件系统. 如linux下的tmpfs 。设置MySQL变量tmpdir ,可以设置多个临时表位置(用分号分割),MySQL将使用轮询方式。

优化办法有。

q  如果必须使用,可以考虑拆分表,把blob,text字段分离到单独的表。

q  如果有许多大字段,可以考虑合并这些字段到一个字段,存储一个大的200kb比存储20个10kb更高效。

q  考虑使用COMPRESS( ),或者在应用层进行压缩,再存储到blob字段中。

注意:如果BLOB列很大,可能需要增大innodb_log_file_size (MySQL错误日志内可能有提示事务日志小了)。

VARCHAR, BLOB和TEXT列,最大行长度稍微小于数据库页的一半。即,最大行长度大约8000字节,在8k以内的话,是可以存储在单个页块里的。

分类: 数据库 标签:

MySQL索引介绍

2016年4月20日 370 views 没有评论

目前MySQL主要支持的几种索引:B树索引(B-tree),哈希索引( hash) ,空间索引Spacial(R-tree),全文索引(full-text)

B树索引介绍

实际MySQL实现的B+树,它的索引如下图(摘录自high performance MySQL )

1

以上是一个简单的图,包括了一个节点块,块内包含一定数量的键值(如key1…keyn) 以及它的叶块(leaf pages),页块内的所有值(Val…)按大小顺序排列,各页块用指针进行连接。

实际的系统,根(root)节点到叶块之间可能有多层的节点块(node page),树的深度取决于表的大小.假设一个块内能存放256个元素,那么3层的树可以存储>1千万的元素.由于有这样的一个层次结构,往往经过2、3次的索引查找,就可以定位到记录,可以大大减少磁盘的读取次数。各页块之间有指针连接,那么还可以方便的进行顺序范围查找。

参考:http://zh.wikipedia.org/wiki/B%2B%E6%A0%91

 

估计查询性能

对小的表,通常能在1次磁盘搜索中找到行(因为索引可能被缓存)。对更大的表,可以使用B-树索引进行估计,将需要log(row_count)/log(index_block_length/3 * 2/(index_length + data_pointer_length))+1次搜索才能找到行。

 

在MySQL中,索引块通常是1024个字节,数据指针通常是4个字节,这对于有一个长度为3(中等整数)的索引的500,000行的表,通过公式可以计算出log(500,000)/log(1024/3*2/(3+4))+1= 4次搜索。

 

上面的索引需要大约500,000 * 7 * 3/2 = 5.2MB,(假设典型情况下索引缓存区填充率为2/3),可以将大部分索引保存在内存中,仅需要1、2次调用从OS读数据来找到记录。

 

然而对于写,将需要4次搜索请求(如上)来找到在哪儿存放新索引,并且通常需要2次搜索来更新这个索引并且写入行。

 

注意,上述讨论并不意味着应用程序的性能将缓慢地以logN 退化!当表格变得更大时,所有内容缓存到OS或SQL服务器后,将仅仅或多或少地更慢。在数据变得太大不能缓存后,将逐渐变得更慢,直到应用程序只能进行磁盘搜索(以logN增加)。为了避免这个问题,应随数据增加而增加innodb_buffer_pool的大小。尽量缓存大部分索引和热点数据。

 

 

哈希索引(hash indexes)

哈希索引是通过构建哈希数组(表) ,通过对值进行hash,查找hash表, 找到真实的行记录的(hash表存储了行记录的指针)。

哈希索引目前只在memory storage engine中支持,也是它的默认索引类型。这是一个不常用的功能。如需了解,可参考

http://dev.MySQL.com/doc/refman/5.1/zh/storage-engines.html

 

空间索引(spacial indexes)

目前在myisam engine中支持. 如需了解,请参考

http://dev.MySQL.com/doc/refman/5.1/zh/spatial-extensions-in-MySQL.html#creating-spatial-indexes

 

 

全文索引(full-text indexes)

全文索引)在myisam engine中支持,如果是其他引擎,一般需要采用第三方的方案,如sphinx,Lucene, Solr等(有个好消息,MySQL 5.6 InnoDB开始支持全文索引了). MySQL在大数据量下的全文索引性能不佳,且无法支持正确的支持中文,一般中文的解决方案,建议采用第三方的解决方案,可参考sphinx等全文索引方案,sphinx可实现快速,高效,可扩展的全文搜索,其性能大大超过MySQL内建的全文搜索

 

一般如果没有特别指明,就是B-Tree索引.由于索引是在存储引擎层实现的,不同的存储引擎的索引实现会有一些差异,以下所述是一些较通用的索引的知识.

逻辑上可以分为:单列索引,复合索引(多列索引),唯一索引(unique),非唯一索引(Non Unique)

 

索引键值的逻辑顺序与索引所服务的表中相应行的物理顺序相同的索引,被称为聚集索引(cluster index),也就是说数据和索引(B+树)在一起,记录是真实的保存在索引的叶子中。有些人也称之为索引组织表,反之为非聚集索引。我们常用的InnoDB表其实就是使用的聚集索引。

聚集索引是一个很重要的概念,InnoDB作为我们最常使用的引擎,我们熟悉了它的数据存储方式,才可能有针对性的对它进行调优。

簇索引的一些优点:

保持相关的的数据在一起,叶子内可保存相邻近的记录。

查找数据通常比非簇索引更快,因为索引和数据存储在一起。

如果充分利用以上,簇索引可极大提升性能, 但簇索引也有许多不足:

簇索引对i/o密集型负荷性能提升最佳,但如果数据是在内存中(访问次序不怎么重要),那么簇索引并没有明显益处;

插入操作很依赖于插入的次序,按primary key的顺序插入是最快的;

更新簇索引列的成本比较高,因为InnoDB不得不移动更新的行到新的位置;

全表扫描的性能差,尤其是行存储的不那么紧密,或者因为页分裂(page split)而存储不连续;

二级索引的叶节点中存储了主键索引的值,如果主键采用得是较长的字符,那么索引可能很大,且通过二级索引查找数据也需要两次索引查找;

 

以下图(来自high performance MySQL 3rd)很好的说明了MYisam和InnoDB的怎样排列我们的表数据。我们对比下InnoDB和MyISAM的数据分布.

2

如上的索引是B+树,各存储引擎大致类似,一颗二叉树,从根节点出发,各子节点指向更深层的子节点或者叶子节点。

我们对比下主键索引和二级索引

InnoDB

主键是一个B树的结构,数据是按照主键(primary key)的顺序来存储的,由于主键是有序的,很显然,对于InnoDB表,最高效的存取方式是按主键取唯一记录或者小范围的主键扫描。如果是其他二级索引(secondary key), 那么也是一个B树的的结构,但是它的leaf page (leaf nodes)存储的不是实际数据指针而是主键的值(key+PKcols). 如果按照二级索引去检索记录,会需要通过存储的主键值再去查找记录,即多了一层join ,这样的好处是当行移动或者页分裂的时候,不用维护二级索引. 当然,如果主键占据过多字节,那么会造成二级索引[……]

Read more

分类: 数据库 标签:

“我看电商”,“再看电商” 读书笔记

2015年6月1日 1,319 views 没有评论

我看电商,再看电商

这是一个运营资深人士-黄岩 写的书,还是很有见地的。推荐对电商运营感兴趣的同学看。

百度腾讯为什么电商领域失败
理念上出了问题

想用模仿淘宝的方式来蚕食淘宝,在对方的地盘上,用对方发明并使用娴熟的武器来试图攻击对方。

缺乏有商务头脑的领军人物

度腾讯都是技术人才汇聚的IT公司,商务人才缺乏,在电商布局上,试图内部繁衍,过于自负,犯了以为自己一样能,样样能的毛病

对电商的定位缺乏深思熟虑

机会很多,比如B2C,比如移动端,需要考虑其他的形态,不一定必须做淘宝类型的平台型

 

电商领域的3个错误

 

认为规模就是效益

规模有可能带来单位成本降低的效益,但规模和效益没有直接因果关系,这个世界有规模没效益的公司比比皆是.

认为流量就是一切

有流量/有客人 固然重要,但更重要的是顾客买单,顾客留存.电商行业往往过分强调登录的用户数,忽视了购买转化过程中的客户流失.

过度依赖价格战

准确的说,电商的价格战,只是一场口水战,并没有真正让顾客得到实惠.

 

怎样管理上市公司的心得

少说,一个人说

不要随意发表言论,要讲的话,归口一个人负责

必践

公布一个预算,或者一个年度目标时,心里要有充分的把握,误差要小于3%,否则人们会怀疑公司管理者的业务把控能力.

 

国内互联网公司,过去这些年大多是借助市场红利,先行一步抢占商机做起来的,内部运营的效率,企业经营的定位,方方面面的管理,都还相当薄弱,小到类似开会要有明确主题,会议要有纪要和落实方案这样很基本的管理要求,很多互联网公司都不到位,往往是老板口头说一个要求,马上实施.

 

 

电商模式

两种模式

买卖模式:如沃尔玛,家乐福,京东的自营。挣的是商品流通效率的钱,通过规模化的采购,降低单件商品销售成本,从中获利。零售公司最基本的任务,就是组织专业化的买卖,营销团队,运用其专业能力和专业知识把货源更精准地组织起来,然后卖给消费者。它最核心的人才在于其买手团队。用户忠诚度高

平台模式:如淘宝,各种B2C网站的开放平台,国内的各种百货公司,平台模式实质上是商业房地产,平台其实就是靠出售顾客流量挣钱.追求顾客客流量的最大化。很难培养用户的忠诚度。

全世界各地的零售业,绝大部分国家,社会零售的主力形态通常都是买卖模式。但在中国,到目前为止,零售业的运行是以平台模式为主的,有各种原因导致出现这种现象。这体现了国内流通领域的低效,以及买卖双方大量额外的交易成本支出。

 

 

亚马逊不用PPT

他们会议一开始递给你一份简要介绍相关数据或现况的A4纸打印稿,几乎都是workd文档,一目了然的把基础数字用书面呈现给你。
因为 不想让大家把精力放在琢磨PPT的格式、字体、图表剪裁上。同时他们认为,任何事情,不管多大的事,如果用两页A4纸不能叙述清楚,那这个人就跟不不明白他自己想要说什么。

 

 

唯品会

代销代运营,唯品会把销售运营的各个环节都自己承担下来,从而保证品牌公司能用最省心的方法去销售自己的商品。对运营有非常高的要求。
模式、经营效率、顾客留存率均有闪亮的表现
唯品会的商业模式有三个基本的支撑点

品牌商品、特价销售、限时。品牌让消费者注意,特价刺激消费者的欲望,限时促成消费者的行为,同时不会对线下渠道造成冲击。这是很完整的用户购买从吸引到想拥有,到掏钱包的连贯营销流程。

唯品会的限时特卖销售的增长,主要来自于三四线品牌,由三四线城镇的用户们所购买,这样的契合,一下子把限时特卖推到一个非常广阔的商品空间。
限时特卖普遍采用聚焦的营销方式,即在一个时间段内,只推出几十款到几百款价格震撼的商品,这就使这些商品有了充足的曝光机会。唯品会的平均每个单品的销售值远高于其他电商。

 

 

传统行业做电商

要有归零的心态
把电商当做一次创业,适宜采用新团队
把电商当作一次投资行为,赋予其早期成长足够的自主空间,不要一上来就干预太多。
 
电商企业的投资可能性
企业的经营模式
企业的运营效率
顾客留存率

 

 

 

 

 

分类: 读书 标签: , ,