Edge 浏览器提供了一个小亮点功能，就是不需要使用其他的插件来生成 URL 的 QR 代码。 这个功能能够让你比较容易的将当前的网页通过发送给手机客户端。 这个功能是隐藏在 URL 中的。 在当前访问的网页中的 URL，单击地址栏的后部分。 随后将会显示URL 被选择了，然后单击生成 QR 的按钮。 随后的界面，将会显示出当前页面的 QR 代码。 这个时候你就可以用手机的 QR 识别或者扫描功能来查看并且分享了。   https://www.ossez.com/t/edge-url-qr/13609

这回小卢同学应该开心坏了，门票免费。 有动态的飞行表演   有静态的飞机展示   时间和地点 https://www.ossez.com/t/topic/13607

晚上烤个鱼，之前鱼要先腌制下。   开炉开烤 https://www.ossez.com/t/topic/13608

可能是因为没有输出就是正常的。 因为并不是是否确定这个地方是否应该有输出。 在尝试使用命令 ./verify-java 对 Java 的运行环境进行校验的时候，并没有任何输出。 也搜索了下官方的文档，也没有这方面的说明，应该是没有输出就说明没有问题，如果有输出的话就说明需要修改的东西在那里。 https://www.ossez.com/t/apache-druid-java/13606

许多公司都已经将 Druid 应用于多种不同的应用场景。请访问 使用 Apache Druid 的公司 页面来了解都有哪些公司使用了 Druid。     如果您的使用场景符合下面的一些特性，那么Druid 将会是一个非常不错的选择： 数据的插入频率非常高，但是更新频率非常低。 大部分的查询为聚合查询（aggregation）和报表查询（reporting queries），例如我们常使用的 “group by” 查询。同时还有一些检索和扫描查询。 查询的延迟被限制在 100ms 到 几秒钟之间。 你的数据具有时间组件（属性）。针对时间相关的属性，Druid 进行特殊的设计和优化。 你可能具有多个数据表，但是查询通常只针对一个大型的分布数据表，但是，查询又可能需要查询多个较小的 lookup 表。 如果你的数据中具有高基数（high cardinality）数据字段，例如 URLs、用户 IDs，但是你需要对这些字段进行快速计数和排序。 你需要从 Kafka，HDFS，文本文件，或者对象存储（例如，AWS S3）中载入数据。 如果你的使用场景是下面的一些情况的话，Druid 不是一个较好的选择： 针对一个已经存在的记录，使用主键（primary key）进行低延迟的更新操作。Druid 支持流式插入（streaming inserts）数据，但是并不很好的支持流式更新（streaming updates）数据。 Druid 的更新操作是通过后台批处理完成的。 你的系统类似的是一个离线的报表系统，查询的延迟不是系统设计的重要考虑。 使用场景中需要对表（Fact Table）进行连接查询，并且针对这个查询你可以介绍比较高的延迟来等待查询的完成。 https://www.ossez.com/t/apache-druid/13604

Apache Druid 是一个实时分析型数据库，旨在对大型数据集进行快速查询和分析（“OLAP” 查询)。 Druid 最常被当做数据库，用以支持实时摄取、高查询性能和高稳定运行的应用场景。 例如，Druid 通常被用来作为图形分析工具的数据源来提供数据，或当有需要高聚和高并发的后端 API。 同时 Druid 也非常适合针对面向事件类型的数据。 通常可以使用 Druid 作为数据源的系统包括有： 点击流量分析（Web 或者移动分析） 网络监测分析（网络性能监控） 服务器存储指标 供应链分析（生产数据指标） 应用性能指标 数字广告分析 商业整合 / OLAP Druid 的核心架构集合了数据仓库（data warehouses），时序数据库（timeseries databases），日志分析系统（logsearch systems）的概念。     如果你对上面的各种数据类型，数据库不是非常了解的话，那么我们建议你进行一些搜索来了解相关的一些定义和提供的功能。 Druid 的一些关键特性包括有： 列示存储格式（Columnar storage format） Druid 使用列式存储，这意味着在一个特定的数据查询中它只需要查询特定的列。 这样的设计极大的提高了部分列查询场景性能。另外，每一列数据都针对特定数据类型做了优化存储，从而能够支持快速扫描和聚合。 可扩展的分布式系统(Scalable distributed system) Druid通常部署在数十到数百台服务器的集群中， 并且可以提供每秒数百万级的数据导入，并且保存有万亿级的数据，同时提供 100ms 到 几秒钟之间的查询延迟。 高性能并发处理（Massively parallel processing） Druid 可以在整个集群中并行处理查询。 实时或者批量数据处理（Realtime or batch ingestion） Druid 可以实时（已经被导入和摄取的数据可立即用于查询）导入摄取数据库或批量导入摄取数据。 自我修复、自我平衡、易于操作（Self-healing, self-balancing, easy to operate） 为集群运维操作人员，要伸缩集群只需添加或删除服务，集群就会在后台自动重新平衡自身，而不会造成任何停机。 如果任何一台 Druid 服务器发生故障，系统将自动绕过损坏的节点而保持无间断运行。 Druid 被设计为 7*24 运行，无需设计任何原因的计划内停机（例如需要更改配置或者进行软件更新）。 原生结合云的容错架构，不丢失数据（Cloud-native, fault-tolerant architecture that won’t lose data） 一旦 Druid 获得了数据，那么获得的数据将会安全的保存在 深度存储 (通常是云存储，HDFS 或共享文件系统)中。 即使单个个 Druid 服务发生故障，你的数据也可以从深度存储中进行恢复。对于仅影响少数 Druid 服务的有限故障，保存的副本可确保在系统恢复期间仍然可以进行查询。 针对快速过滤的索引（Indexes for quick filtering） Druid 使用 Roaring 或 CONCISE 来压缩 bitmap indexes 后来创建索引，以支持快速过滤和跨多列搜索。 基于时间的分区（Time-based partitioning） Druid 首先按时间对数据进行分区，同时也可以根据其他字段进行分区。 这意味着基于时间的查询将仅访问与查询时间范围匹配的分区，这将大大提高基于时间的数据处理性能。 近似算法(Approximate algorithms) Druid应用了近似 count-distinct，近似排序以及近似直方图和分位数计算的算法。 这些算法占用有限的内存使用量，通常比精确计算要快得多。对于精度要求比速度更重要的场景，Druid 还提供了exact count-distinct 和 exact ranking。 在数据摄取的时候自动进行汇总(Automatic summarization at ingest time) Druid 支持在数据摄取阶段可选地进行数据汇总，这种汇总会部分预先聚合您的数据，并可以节省大量成本并提高性能。   https://www.ossez.com/t/druid/13603

Apache Druid 是一个高性能的实时分析型数据库。 Druid 的主要价值是能够减少检查和查找的时间。 Druid 的工作流被设计为能够快速进行查询并且能够对实时的情况进行分析。 Druid 具有非常强大的 UI 界面，能够让用户进行 即席查询（Ad-Hoc Query），或者能够处理高并发。 针对数据库仓库或一系列的用户使用案例，可以将 Druid 考虑为这些使用场景的开源解决方案。 Ad-Hoc Query 如果你对 Ad-Hoc Query （即席查询）的概念和使用不是是否清楚的话，请自行搜索相关的技术文档。 简单来说：即席查询（Ad Hoc）是用户根据自己的需求，灵活的选择查询条件，系统能够根据用户的选择生成相应的统计报表。 即席查询与普通应用查询最大的不同是普通的应用查询是定制开发的，而即席查询是由用户自定义查询条件的。 即席查询是指那些用户在使用系统时，根据自己当时的需求定义的查询。 对即席查询来说，用户需要查询的内容在开始的时候是不知道的，因此查询需要更多的维度，查询很多时候都是在运行的时候再构建的。 Druid 的查询能够很好的支持即席查询，但同时也带来一些复杂性和学习曲线。 云原生、流原生的分析型数据库 Druid专为需要快速数据查询与摄入的工作流程而设计，在即时数据可见性、即席查询、运营分析以及高并发等方面表现非常出色。 在实际中的众多场景下数据仓库解决方案，都可以考虑将 Druid 作为一种开源的替代解决方案。 请访问 Druid 资源快速导航 页面来简要查看我们收集的相关技术文档和使用案例。 轻松与现有的数据源 Druid 原生支持从 Kafka ，Amazon Kinesis 等消息总线中流式的消费数据， 也同时支持从 HDFS ， Amazon S3 等存储服务中批量加载数据。 较传统方案提升近百倍的效率 Druid 创新地在架构设计上吸收和结合了数据仓库， 时序数据库 以及 检索系统 的优势。 在已完成的 基准测试 中针对传统数据输入和查询的解决方案展现强大的性能。 解锁了一种新型的工作流程 Druid 为点击流、APM、供应链、网络监测、市场营销以及其他事件驱动类型的数据分析解锁了一种新型的查询与工作流程， 它专为实时和历史数据高效快速的即席查询而设计。 强大部署能力 Druid 可部署在 AWS/GCP/Azure, 混合云, Kubernetes, 以及裸机上，针对中文环境阿里的云计算平台也提供了无缝集成。 无论在云上还是本地，Druid 都可以轻松部署在基于 *NIX 环境的任何商用硬件上。部署 Druid 是非常简单的，包括集群的扩容或者下线都也同样很简单。   https://www.ossez.com/t/apache-druid/13602

在社区运行一段时间以后，我们可能需要对社区的内容进行调整。 这篇文章介绍了如何在 Discourse 中批量从一个分类移动到另一个分类。     例如，我们需要将下面的主题批量从当前的分类中移动到另外一个叫做 数据库 的分类中。 操作步骤 下面描述了相关的步骤。 选择 选择你需要移动的主题。 这个是操作的第一步，如下图所示，选择主题前面的图标。 然后所有的主题都变成可以选择的选项了，然后再在页面的右侧单击调整的按钮。     批量操作 当你选择批量操作以后，当前的浏览器界面就会弹出一个小对话框。 在这个小对话框中，你可以选择设置分类。     选择设置分类 在随后的界面中，选择设置的分类。     然后保存就可以了。 经过上面的步骤就可以完成对主题的分类的批量移动了。 需要注意的是，主题分类的批量移动不会修改当前主题的的排序，如果你使用编辑方式在主题内调整分类的话，那么调整的主题分类将会排序到第一位。 这是因为在主题内对分类的调整方式等于修改了主题，Discourse 对主题的修改是会更新主题修改日期的，在 Discourse 首页中对页面的排序是按照主题修改后的时间进行排序的，因此会将修改后的主题排序在最前面。   https://www.ossez.com/t/discourse/13601

在 Discourse 中使用标签的时候，发现 Discourse 创建的标签都是小写的。     有没有办法让 Discourse 创建的标签可以是大写呢？ 深入和解答 Discourse 是允许使用大写的标签的，可以在后台的控制台中进行配置。     可以通过取消上面的选择项来允许标签使用大写。 但是，不建议取消这个的选择。例如标签中的 home = Home = hOme = homE 字符，如果允许大写的话，上面的标签是不相同的，但是实际上，上面的标签是相同的。 基于上面的考虑，所以标签被设置为只使用小写。 例如 GitHub 等很多大的平台都只能使用小写标签。   https://www.ossez.com/t/discourse-tag/13600

乡村振兴 塘付传统村落，作为祖祖辈辈、世世代代塘付村人的生活载体，物质、精神生活家园，虽然跨越了600多年的漫长历史，有的传统建筑已消失，村面貌有些全非了，但是世代先辈留在传统村落里的传统文化并没有消失，而今仍在塘付村民间传承。 为了村落振兴，塘付村在继承传统文化的同时，提出了新的村民要求，倡导村民： 坚持社会主义核心价值观； 爱国、爱村、爱家、爱业； 保护生态环境； 树立文明新风； 诚信经营； 孝老爱幼； 弘扬奉信、友爱、互助、进步； 树立“村盛我荣，村衰我耻”的价值观念 村里的这些村规民约，对建设、发展、振兴塘付村是具有促进作用的，也是具有积极意义的。 不过在村落振兴发展、建设社会主义新农村的同时，要加强对传统村落古宅民居建筑的保护。 传统民居建筑是先祖们心血和汗水凝固而成的，历史的东西是有价值的东西，既是历史的记忆，也是塘付村人的宝贵遗产，千万记住，古宅民居建筑失去不会再现。 塘付村有丰富的旅游资源，开发前景十分可观。 山上有层层叠叠的梯田，地下有千姿百态的溶洞，村边有年代久远的参天大树，村中有奇石林立的大水塘，有民居古建筑；还有鱼田洞水库，民间传说故事，英雄事迹，民俗风情，地方特产等等，一经作为旅游资源开发出来，给塘付村人带来的经济收入是非常可观的。 笔者建议在做好民俗文化活动的同时，做好乡村振兴工作。   https://www.ossez.com/t/topic/13599