TDengine™ is a next generation data historian purpose-built for Industry 4.0 and Industrial IoT. It enables real-time data ingestion, storage, analysis, and distribution of petabytes per day, generated by billions of sensors and data collectors. With TDengine making big data affordable and accessible, digital transformation has never been easier.

TDengine

Welcome to HackerNoon’s interview series. This section is curated by our Editorial team to spotlight bold and disruptive startups across the globe. If you’ve been nominated, and answer these questions Startups-Of-The-Year create a brand profile here. Hey Hackers, TDengine has been nominated in HackerNoon's annual Startup of the Year awards in Campbell, CA. Please vote for us here: https://hackernoon.com/startups/north-america/north-america-campbell-ca-usa Read more about us below to understand why we deserve your vote. Meet TDengine is the only open-source time-series database to solve the high cardinality issue with a unique architecture supporting billions of data points while outperforming general-purpose and legacy time-series databases in data ingestion, querying, and data compression. TDengine TDengine combines a database with caching, stream processing, and data subscription as a complete, purpose-built solution for time-series data optimized for the Internet of Things (IoT), connected cars, industrial IoT, and DevOps. In less than four years, TDengine has become immensely popular, garnered over 21,000 stars on GitHub, 4,400 forks, and over 300,000 installations in more than 50 countries worldwide, and drove a 200% increase in customer adoption in 2022. My Role As the founder, core developer, and chief executive officer of TDengine, I have led the development of TDengine from the ground up, guiding the product roadmap and features to build an innovative open-source time-series database. My primary role is providing strategic vision and technical direction for our talented teams of developers and engineers as we seek to continuously advance TDengine as a leading platform for time-series data management and analytics. I oversee all aspects of our company's operations, from products to people, fostering a culture of excellence and innovation. As CEO, I aim to lead TDengine to the forefront of the time-series data space while managing a high-performing global team committed to delivering outstanding value for our users and customers. But having a background in software development myself, I recognize the necessity of community support and developer enablement in the open-source space and am committed to making a product that helps developers succeed above all. How We're Disrupting/Improving the Time-Series Database Industry At TDengine, we recognize that the Internet of Things (IoT) and connected device deployments generate massive amounts of time-stamped data daily. This time-series data is extremely valuable for analysis but also incredibly challenging from a data management perspective. Many existing databases need to be explicitly architected for the demands of IoT and time-series workloads. This often results in organizations hitting scalability or cost barriers trying to leverage IoT data, especially as device volumes grow. With TDengine, our core innovation is providing an open-source time-series database designed from the ground up to ingest, process, and analyze IoT and time-series data at scale. By optimizing everything from storage to query processing for time-series needs, we empower organizations to capitalize on the value of their connected device or sensor data. This unlocks game-changing possibilities for companies to build transformative IoT applications for use cases ranging from predictive maintenance to smart cities and beyond. Standing Out From The Crowd There are a few key ways in which TDengine differentiates itself in the database landscape: We are laser-focused on time-series data workloads. TDengine is purpose-built and optimized specifically for managing and analyzing time-series data at scale. This differentiates us from general-purpose databases that treat time series as just another data type. Our innovative technical architecture delivers game-changing performance for ingesting, storing, and querying time-series data. TSBS benchmarks show that we outperform other databases by orders of magnitude in metrics like ingestion speed while reducing storage costs. A unique advantage of our platform is the ability to share time-series data insights across teams and systems easily. We offer a variety of connectors – including developer-focused options like Kafka and industry interfaces like PI System – enabling customers to unlock the full value of their time-series data for advanced analytics and AI applications. We also support standard SQL for flexibility and ease of use, plus extensions for specialized time-series queries, so users get the best of both worlds. As an open-source platform, we accept contributions from our community and offer our OSS edition to developers for free. Our Predictions/Thoughts on the Time-Series Database Industry in 2023 As we enter 2023, I foresee significant growth for the time-series database market, especially among traditional industrial organizations. The reason is simple - with the rise of IoT, more physical assets and processes are connected, generating massive amounts of time-stamped data. However, most legacy IT systems were not built to handle the extreme ingestion speeds, storage demands, and analytical capabilities required to capitalize on large-scale industrial time-series data. As companies look to modernize, purpose-built time-series databases will be vital in overcoming these challenges. Rather than retrofitting general-purpose databases, we believe businesses need solutions explicitly optimized for time-series workloads from the ground up. This allows them to fully harness time-series data to advance IoT-driven initiatives around predictive maintenance, operational optimization, and more. As IT modernization accelerates, we foresee solid industry-wide growth for time-series databases. To remain competitive, legacy sectors like manufacturing, energy, and transportation must embrace these modern data platforms. The companies that successfully transform their time-series data architecture position themselves to survive and thrive with IoT innovation in 2023 and beyond. It's an exciting time for industrial organizations to tap into the power of time-series data. What word defines the state of time-series databases in 2023? Momentum. That's the word I'd use to define the state of time-series databases in 2023. Time-series databases have tremendous momentum right now, driven by the explosion of IoT devices, the maturing of purpose-built time-series technology, and advances in cloud infrastructure and analytics. Together, these trends are creating a surge in adoption as time-series data transitions from an exciting concept to a core building block underpinning digital transformation across industries. With IoT continuing to increase and time-series databases seeing increasing adoption across industries, 2023 will be a breakout year. We see solid tailwinds for time-series databases to become a mainstream pillar of the modern data stack as organizations embrace time-series data-centric strategies. The space has a fascinating trajectory poised to accelerate in 2023. Why we decided to participate in HackerNoon's Startup of the Year awards We're thrilled to participate in HackerNoon's Startup of the Year awards to gain valuable exposure for our emerging company within the tech community. As a startup, telling our story and showcasing our platform to new audiences is always challenging, so the visibility and credibility associated with these prestigious awards provide an incredible opportunity to reach potential users, partners, and developers we otherwise may not have. Competing also lets us benchmark against peers and learn from the evaluation process. Earning recognition further validates our team's efforts in a crowded startup landscape. Ultimately, we build technology to solve real problems, so participating in these awards helps spread our vision and brings us one step closer to becoming a trusted brand worldwide. It's all about increasing awareness of our innovative solutions. Final Thoughts At TDengine, we are on a mission to revolutionize how organizations harness the power of time-series data. Our journey so far has been exhilarating - from conceptualizing a purpose-built time-series database to leading TDengine's astronomical rise with over 21,000 GitHub stars and 300,000 installations globally in just four years. But this is only the beginning. Looking ahead, we are committed to continuous innovation to make TDengine the go-to open-source platform for time-series workloads. And we are humbled by the opportunity through platforms like HackerNoon to tell our story and bring TDengine to more users worldwide. We hope sharing our vision and unique approach to time-series data will resonate with the HackerNoon community. Thank you for considering our startup on this exciting journey to shape the future of time-series technology. Please vote for TDengine as Startup of the Year today! Your support allows us to spread our mission even further. Vote for us today: https://hackernoon.com/startups/north-america/north-america-campbell-ca-usa

Startups of the Year 2023: TDengine - A Open-Source Time-Series Database

Motivation and Introduction As part of the software team at Nevados we are building an operations and monitoring platform for the Nevados All Terrain Tracker®. A solar tracker is a device that orients a solar panel toward the sun. Every solar tracker constantly sends status information and readings, such as the current angle, temperature, voltages, etc. to our platform and we need to store this information for analysis and visualization. If the tracker is configured to send data every 5 seconds, we have 17,280 data points per tracker per day, 518,400 data points per tracker per month. That sums up a lot of information. This kind of data is called "time-series data" and as for all complex problems in software, there are several solutions (Time Series Databases) for it. The most famous ones being InfluxDB and TimescaleDB. For our platform, we decided to work with , a relatively new product that is optimized for IoT applications and works with the SQL query language. TDEngine There were several arguments for this decision: TDEngine is open source is optimized for IoT applications uses SQL, which is a language we are familiar with is available as a managed service and we can focus on building our application is easy to run locally via Docker In this article, we'll go through the setup of a TDEngine database and tables and how to craft a GraphQL schema that allows us to query the data from various clients and applications. Getting started with TDEngine The easiest way to get started with TDEngine is to use their cloud service. Go to the and create an account. They have a few public databases we can use, which is great to put together a demo or experiment with queries. TDEngine If you want to run TDEngine locally, you can use the Docker image and to retrieve data from various sources and send them to the database, such as system information, ping statistics etc. Telegraf version: '3.9'

services:
  tdengine:
    restart: always
    image: tdengine/tdengine:latest
    hostname: tdengine
    container_name: tdengine

    ports:
      - 6030:6030
      - 6041:6041
      - 6043-6049:6043-6049
      - 6043-6049:6043-6049/udp
    volumes:
      - data:/var/lib/taos

  telegraf:
    image: telegraf:latest
    links:
      - tdengine
    env_file: .env
    volumes:
      - ./telegraf.conf:/etc/telegraf/telegraf.conf Check out the and the . In short, this would look something like this to connect to an MQTT topic: official documentation for the Telegraf configuration TDEngine documentation on Telegraf [agent]
  interval = "5s"
  round_interval = true
  omit_hostname = true

[[processors.printer]]

[[outputs.http]]
  url = "http://127.0.0.1:6041/influxdb/v1/write?db=telegraf"
  method = "POST"
  timeout = "5s"
  username = "root"
  password = "taosdata"
  data_format = "influx"

[[inputs.mqtt_consumer]]
  topics = [
    "devices/+/trackers",
  ] Instead of setting everything up locally and waiting for the database to fill with information, we'll use the public database for this article, which contains ship movements from the 5 major US ports. Using TDEngine with public ship movement data By default, the tables in TDEngine have an implicit schema, which means the schema adapts to the data that is written to the database. This is great for bootstrapping, but eventually, we want to switch to an explicit schema to avoid issues with incoming data. One thing that takes a little time to get used to is their concept of ("STable" for short). In TDEngine there are tags (keys) and columns (data). For each key combination, a "table" is created. All tables are grouped in the STable. Super Tables Looking at the database, they have one STable called which contains a lot of tables. Usually, we do not want to query on a per-table basis, but always use the STable to get accumulated data from all tables. vessel ais_data TDEngine has a function which allows us to inspect the schema of a table or STable. The has the following schema: DESCRIBE ais_data The STable has two keys and six data columns. The keys are the and the . We can use regular SQL statements to query the data: mmsi name SELECT ts, name, latitude, longitude FROM vessel.ais_data LIMIT 100;

ts                        name      latitude   longitude
2023-08-11T22:07:02.419Z  GERONIMO  37.921673 -122.40928
2023-08-11T22:21:48.985Z  GERONIMO  37.921688 -122.40926
2023-08-11T22:25:08.784Z  GERONIMO  37.92169  -122.40926
... Keep in mind that time-series data is usually very large, so we should always limit the resultset. There are a few time-series specific functions that we can use, like which groups results by key and is useful to get the latest update individual keys. For example: PARTITION BY SELECT last_row(ts, name, latitude, longitude) FROM vessel.ais_data PARTITION BY name;

ts                        name      latitude   longitude
2023-09-08T13:09:34.951Z  SAN SABA  29.375961 -94.86894
2023-09-07T18:05:01.230Z  SELENA  33.678585 -118.1954
2023-09-01T17:23:24.145Z  SOME TUESDAY  33.676563 -118.230606
... I recommend reading their for more examples. Before we move on, head to "Programming", "Node.js" and retrieve your and variables. SQL Documentation TDENGINE_CLOUD_URL TDENGINE_CLOUD_TOKEN GraphQL with Nexus.js, Fastify and Mercurius GraphQL is pretty well known these days and there are lots of good articles about it. We chose the technology as we collect and process information from different sources and GraphQL allows us to combine them into a single API transparently. We'll use the amazing framework (by now the default choice for Node.js applications) and the adapter. The teams of Mercurius and Fastify worked together for a seamless experience and it's a great choice GraphQL APIs with a focus on performance. is a tool to build/generate the schema and resolvers, so we do not have to write everything by hand. Fastify Mercurius GraphQL Nexus There's a bit of setup code etc. to be done, which I'll skip here. You can find a full example on . GitHub - tdengine-graphql-example I want to elaborate on two things in this article that are rather specific: the TDEngine Query library the GraphQL schema with Nexus TDEngine Query library TDEngine has a that allows us to query the database. This makes it easy to connect and send queries, unfortunately the responses are a little difficult to work with. So we wrote a little wrapper: Node.js library 'use strict'

import tdengine from '@tdengine/rest'
import { tdEngineToken, tdEngineUrl } from '../config.js'
import parseFields from 'graphql-parse-fields'

const { options: tdOptions, connect: tdConnect } = tdengine
tdOptions.query = { token: tdEngineToken }
tdOptions.url = tdEngineUrl

export default function TdEngine(log) {
  this.log = log
  const conn = tdConnect(tdOptions)
  this.cursor = conn.cursor()
}

TdEngine.prototype.fetchData = async function fetchData(sql) {
  this.log.debug('fetchData()')
  this.log.debug(sql)

  const result = await this.cursor.query(sql)
  const data = result.getData()
  const errorCode = result.getErrCode()
  const columns = result.getMeta()

  if (errorCode !== 0) {
    this.log.error(`fetchData() error: ${result.getErrStr()}`)
    throw new Error(result.getErrStr())
  }

  return data.map((r) => {
    const res = {}
    r.forEach((c, idx) => {
      const columnName = columns[idx].columnName
        .replace(/`/g, '')
        .replace('last_row(', '')
        .replace(')', '')
      if (c !== null) {
        res[columnName] = c
      }
    })
    return res
  })
} This returns a TDEngine object that can be passed into GraphQL context. We'll primarily be using the function where we can pass in a SQL query and get the results back as an array of objects. TDEngine returns the metadata (columns), errors and data separately. We'll use the metadata to map the columns into a regular list of objects. A special case here is the function. The columns are returned as , etc. and we want to remove the part so the attribute maps 1:1 to the GraphQL schema. This is done in the part. fetchData last_row last_row(ts) last_row(name) last_row columnName.replace GraphQL Schema Unfortunately there is no schema generator like for TDEngine and we don't want to write and maintain a pure GraphQL schema, so we'll use Nexus.js to help us with that. We'll start with two basic types: and (which is a scalar type). and are two different types to display the date as a timestamp or as a date string. This is useful for the client application (and during development), as it can decide which format to use. allows us to use the type as a function in the schema. We can resolve the right here in the type definition to use the original timestamp value. Postgraphile VesselMovement Timestamp Timestamp TDDate asNexusMethod VesselMovement TDDate ts import { scalarType, objectType } from 'nexus'

export const Timestamp = scalarType({
  name: 'Timestamp',
  asNexusMethod: 'ts',
  description: 'TDEngine Timestamp',
  serialize(value) {
    return new Date(value).getTime()
  }
})

export const TDDate = scalarType({
  name: 'TDDate',
  asNexusMethod: 'tdDate',
  description: 'TDEngine Timestamp as Date',
  serialize(value) {
    return new Date(value).toJSON()
  }
})

export const VesselMovement = objectType({
  name: 'VesselMovement',
  definition(t) {
    t.ts('ts')
    t.tdDate('date', { resolve: (root) => root.ts })
    t.string('mmsi')
    t.string('name')
    t.float('latitude')
    t.float('longitude')
    t.float('speed')
    t.float('heading')
    t.int('nav_status')
  }
}) For time-series types, we use the or suffix for a clear separation of relational and time-series types in the interface. Movement Series Now we can define the Query. We'll start with a simple query to get the latest movements from TDEngine: import { objectType } from 'nexus'

export const GenericQueries = objectType({
  name: 'Query',
  definition(t) {
    t.list.field('latestMovements', {
      type: 'VesselMovement',
      resolve: async (root, args, { tdEngine }, info) => {
        const fields = filterFields(info)
        return tdEngine.fetchData(
          `select last_row(${fields}) from vessel.ais_data partition by mmsi;`
        )
      }
    })
  }
}) is a great tool to test the API and explore the schema, you can enable it by passing in Mercurius. With the query, we can see the latest movements of vessels grouped by . Let's go a little further though. One of the biggest advantages of GraphQL is that is is a transparent layer to the client or application. We can fetch data from multiple sources and combine them into the same schema. GraphiQL graphiql.enabled = true mmsi Unfortunately, I wasn't able to find an easy/free API with extensive vessel information. There is , but they only provide the , and in their Vessel response (which we already have in TDEngine). For the sake of the example, we assume we do not have the in our database and we need to retrieve it from Sinay. With the we could also query CO2 emissions for a vessel or another API could be used to retrieve an image, the flag or other information, all of which can be combined in the type. Sinay name mmsi imo name imo Vessel export const Vessel = objectType({
  name: 'Vessel',
  definition(t) {
    t.string('mmsi')
    t.string('name')
    t.nullable.string('imo')
    t.list.field('movements', { type: 'VesselMovement' })
  }
}) As you can see here, we can include a list field with the time-series data from TDEngine. We'll add another query to fetch the vessel information and the resolver allows us to combine the data from TDEngine and Sinay: movements t.field('vessel', {
  type: 'Vessel',
  args: {
    mmsi: 'String'
  },
  resolve: async (root, args, { tdEngine }, info) => {
    const waiting = [
      getVesselInformation(args.mmsi),
      tdEngine.fetchData(
        `select * from vessel.ais_data where mmsi = '${args.mmsi}' order by ts desc limit 10;`
      )
    ]

    const results = await Promise.all(waiting)
    return {
      ...results[0][0],
      movements: results[1]
    }
  }
}) 🎉 and here we have a working GraphQL API returning rows from TDEngine for a specific vessel we requested. is a simple wrapper to fetch data from Sinay. We'll add the TDEngine results into the attribute and GraphQL will take care of the rest and map everything to the schema. getVesselInformation() movements Note: SQL Injection As with any SQL database, we need to be careful with user input. In the example above we use the input directly, which makes this query vulnerable to SQL injections. For the sake of the example, we'll ignore this for now, but in "real world" applications, we should always sanitize user input. There are several small libraries around to sanitize strings, in most cases we only rely on numbers (pagination, limit etc.) and enums (sort order), which GraphQL checks for us. mmsi Thanks to Dmitry Zaets for pointing this out! Optimizations There are a few things that go beyond the scope of this article, but I want to mention them briefly: Pothos as spiritual successor to Nexus.js When we started the project, Nexus.js was the best choice to generate our GraphQL schema. Although stable and , it lacks maintenance and updates. There is a plugin-based GraphQL schema builder called which is a bit more modern and actively maintained. If you're starting a new project, I probably recommend using Pothos instead of Nexus.js. somewhat feature-complete Pothos Thanks to Mo Sattler for pointing this out! Field Resolvers As you can see in the resolver above, both data sources are immediately fetched and processed. This means if the query is only for the , we still fetch the for the response. And if the query is for the only, we still fetch the name from Sinay and potentially pay for the request. Vessel name movements movements That's a GraphQL anti-pattern and we can improve the performance by using the field information to only fetch the data that is requested. Resolvers have the field information as the fourth argument, but they're pretty difficult to work with. Instead, we can use to get a simple object of the requested fields and adjust the resolver logic. graphql-parse-fields SQL Query Optimizations In our example queries, we use to fetch all columns from the database even if they're not needed. This is obviously pretty bad and we can use the same field parser to optimize the sql queries: select * export function filterFields(info, context) {
  const invalidFields = ['__typename', 'date']
  const parsedFields = parseFields(info)
  const fields = context ? parsedFields[context] : parsedFields
  const filteredFields = Object.keys(fields).filter(
    (f) => !invalidFields.includes(f)
  )
  return filteredFields.join(',')
} This function returns a comma-separated list of fields from the GraphQL info. const fields = filterFields(info)
return tdEngine.fetchData(
  `select last_row(${fields}) from vessel.ais_data partition by mmsi;`
) If we request , and , the query would look like this: ts latitude longitude select last_row(ts, latitude, longitude) from vessel.ais_data partition by mmsi; With only a few columns in this table this might not matter much, but with more tables and complex queries, this can make a huge difference in application performance. Time Series functions TDEngine has some time-series specific extensions that should be used to improve performance. For example, to retrieve the latest entry, a traditional SQL query: SELECT ts, name, latitude, longitude FROM vessel.ais_data order by ts desc limit 1; Takes 653ms to execute, while the "TDEngine" query takes only 145ms: SELECT last_row(ts, name, latitude, longitude) FROM vessel.ais_data; There are configuration options for each table to optimize for last_row/first_row functions and other cache settings. I recommend reading the . TDEngine documentation Conclusion The simple version: In this article, we've set up a TDEngine time-series database and defined a GraphQL schema to allow client applications to connect & query data. There's a lot more to it. We have a boilerplate project to combine complex time-series data with relational data in a transparent interface. At Nevados, we're using PostgreSQL as a primary database and retrieve time-series data the same way as in the example above. This is a great way to combine data from multiple sources in a single API. Another benefit is that the data is only fetched when requested, which adds a lot of flexibility to the client application. Last but not least, the GraphQL Schema works as a documentation and contract, so we can easily tick the "API Documentation" box. movement , please or . If you have any questions or comments reach out on BlueSky join the discussion on GitHub Also published . here

Creating a Time Series Database With TDEngine and GraphQL

TDEngine এবং GraphQL দিয়ে একটি টাইম সিরিজ ডেটাবেস তৈরি করা

Erstellen einer Zeitreihendatenbank mit TDEngine und GraphQL

Creación de una base de datos de series temporales con TDEngine y GraphQL

Création d'une base de données de séries chronologiques avec TDEngine et GraphQL

TDEngine और GraphQL के साथ एक टाइम सीरीज़ डेटाबेस बनाना

TDEngine と GraphQL を使用した時系列データベースの作成

TDEngine 및 GraphQL을 사용하여 시계열 데이터베이스 생성

Criando um banco de dados de série temporal com TDEngine e GraphQL

Создание базы данных временных рядов с помощью TDEngine и GraphQL

TDEngine ve GraphQL ile Zaman Serisi Veritabanı Oluşturma

Tạo cơ sở dữ liệu chuỗi thời gian với TDEngine và GraphQL

使用 TDEngine 和 GraphQL 创建时间序列数据库

Republished from TDengine blog. I am a Director of Solutions Engineering at TDengine. Time-series databases (TSDB) are aimed at processing time-stamped data points in an efficient way. The data model is the most important part of any data management system. Different TSDBs adopt different data models. To help developers deploy the right TSDB for their application, this blog compares data models for a few popular TSDBs on GitHub. Particularly we look at InfluxDB, TDengine, TimeScale, Prometheus, OpenTSDB, and QuestDB. A time-series dataset contains a sequence of time-stamped metrics. The metrics are always generated by a single device, sensor, or data collection agent. Let’s call it a data collection point, DCP. Each DCP has static attributes, like serial number, model, color, hostname, app name, etc. In TSDB, these attributes are treated as labels or tags. These tags/labels actually are dimensional data and can be used to filter, group, or match the time series during analysis. To make it easier to understand, let’s use connected vehicles as an example in this blog. Each vehicle reports its GPS position(x, y, z) to a server periodically. Each vehicle has its own unique VIN (vehicle identification number), brand, and model. We will look at the data model from the following dimensions: Type of data model – Relational vs Tag Set Column model – Single vs Multi Supported data types – Numerical only vs varied Tag Set Data Model While TimeScale, TDengine, and QuestDB adopt a relational data model, OpenTSDB, Prometheus, and InfluxDB adopt a Tag Set data model. Prometheus shares the same tag set data model as OpenTSDB with some minor enhancements and so in this blog, we will not address OpenTSDB specifically. In a tag set data model, every time series is uniquely identified by a metric name (measurement in InfluxDB nomenclature) and a set of labels (tags in InfluxDB nomenclature ). In our connected vehicles scenario, each time series is identified by: GPS Coordinates + VIN + Brand + Model For Prometheus/OpenTSDB, a time-series for connected vehicles could be written like this: gps_x { vin=”vin1”, brand=”tesla”, model=”s3”} gps_y { vin=”vin1”, brand=”tesla”, model=”s3”} gps_z { vin=”vin1”, brand=”tesla”, model=”s3”} In the case of InfluxDB,  the time-series could be written as: gps, vin=vin1, brand=tesla, model=s3 The Tag Set model resembles NoSQL, where schema and indexes are not required to be defined. Indexes on tags are created automatically, but indexes on metrics are not created. In fact, indexes on metrics are not allowed to be created which is a shortcoming of the tag set model. On the other handwriting to the database is very simple and it is quite easy to prototype simplistic applications. This makes it very attractive for developers. To aggregate multiple time-series, a label/tag set filter has to be applied. If we add one more tag or change the tag value, it is treated as a different time-series. While typically tags may not be changed, as IoT grows and devices become more complex and capable of capturing more data, we can anticipate that tags/labels will in fact be added probably quite frequently. In our simple connected vehicles scenario, if we add color as one more dimension for analysis, the Tag Set model treats it as a new time-series even though it is actually not. Additionally, in the Tag Set model, tags are always treated as strings, and no other data types are supported. This makes it impossible to filter within a range for example. Another drawback of the Tag Set data model is that the query language is always proprietary. The early version of InfluxDB’s query language is SQL-like, but the new version is powered by its proprietary Flux query language. Prometheus also has its own query language, PromQL, and OpenTSDB adopts a set of its own APIs for querying. Proprietary query languages impose an unnecessary learning cost which is better spent on robust development especially in a fast-moving IoT world. Relational Data Model In applications that use a relational data model, the schema is always defined first. In the case of time-series data, there is always a timestamp column. In addition, each metric has a dedicated column and a data type. There are advantages to this. For e.g. the design of the schema is useful in validating the user’s input. Requiring schema design at the beginning of the project forces developers to be thoughtful about the data model, which reduces the effort for analysis and change management later on and reduces risk. One of the best advantages of the relational data model is the query language – SQL. SQL is both an ISO and an ANSI standard. TimeScale, QuestDB, and TDengine all support SQL with some extensions. Since SQL is supported, many analytical tools, BI tools, and graphing tools can be used without any effort and queries can be reused with little or no change. Defining a schema is viewed as a hurdle for developers used to NoSQL models who may want to adopt a relational data model. To overcome this problem, both TDengine and QuestDB support schemaless data ingestion with built-in support for automatic table creation. TDengine supports both InfluxDB’s Line Protocol and OpenTSDB’s telnet and JSON format protocols. TDengine has out-of-box support for Telegraf, collectd, StatsD and other agents which can write data directly into TDengine. A relational data model, of course, defines a schema for collected metrics. But TDengine, TimeScale and QuestDB adopt different ways to handle labels/tags associated with each data collection point. TimeScale For TimeScale, we have to create a table to store collected metrics and then convert this table into a HyperTable.  In addition, we also need to create another table to store the tags. If we want to execute a basic query such as aggregation over a set of time-series, we need to perform a JOIN operation between the HyperTable and the tags table. Given our connected vehicle scenario, the following SQL statements shall be executed: create table vehicles(vin SERIAL PRIMARY KEY, brand VARCHAR(20), model VARCHAR(20)); create table vehicle_data(time TIMESTAMPTZ NOT NULL, vin SERIAL, x DOUBLE PRECISION, y DOUBLE PRECISION, z DOUBLE PRECISION, FOREIGN KEY (vin) REFERENCES vehicles (vin)); If we want to retrieve data for a specific vehicle the SQL is: select * from vehicle_data where vin=”vin1” If you want to query all the data for Tesla Model S3, the SQL is： select * from vehicle_data join vehicles on vehicle_data.vin= vehicles.vin where brand=“tesla” and model=”s3” TDengine TDengine’s developers have designed a storage engine that is highly optimized for time-series data. To enhance the overall storage and query performance, TDengine requires a table for each time-series or data collection point. Furthermore, TDengine introduces a novel concept called the SuperTable (STable). An STable is used to describe a category of devices which generate the same metrics. An STable’s schema includes two parts – one part for metrics, and another part for tags. For our connected vehicle scenario, the STable is created as below: create table vehicle (ts timestamp, double x, double y, double z) tags (brand nchar(16), model nchar(16)) For each time-series or data collection point, a table needs to be created. In TDengine, this table is created by using a STable as a template with tag value assigned. For example, for a vehicle vin1, the table is created as follows: create table vin1 using vehicle tags (“tesla”, “s3); In other words, compared to a regular table, the table for each time-series is attached to a set of tags. The table name is unique in a database and can be set to a VIN in our connected vehicle scenario. To query the data on a specific vehicle, the SQL statement will be： select * from vin1 To run a query over a set of vehicles, it queries on STable instead of the table, the SQL statement will is: select * from vehicle where brand = “tesla” and model = “s3”; By not requiring unnecessary joins the query in TDengine is much simpler when compared to queries in TimeScale. QuestDB QuestDB puts tags and metrics together in the table definition. For our connected vehicle scenario,  the created table looks like this: create vehicle(ts timestamp, vin symbol, brand symbol, model symbol, x double, y double, z double) If you want to run query on a set of vehicles, the SQL will be like: select * from vehicle where brand = “tesla” and model = “s3”; It’s similar to TDengine; simple and straightforward. If you want to query data on a specific vehicle, the SQL will be like: select * from vehicle where vin = "vin1"; Putting metrics and tags in a single table is a natural way for data modeling, but it raises a challenge for storage efficiency and query performance. Single Column vs Multi-column Prometheus and OpenTSDB adopt a single-column model. Each metric is treated as a different time series. In our connected vehicle case, GPS position (x, y and z) requires 3-time series. While the single-column concept is very easy to understand and quite flexible, it consumes significantly more resources. In our connected vehicle example, the GPS position x, y and z each requires a timestamp which doubles the data size in both RAM and on disk. Reading the GPS position requires reading from 3-time series which leads to much longer latency. InfluxDB, TDengine, TimeScale and QuestDB all support multi-column. Typically, a time series will contain multiple metrics which share the same timestamp. Obviously, multi-column support saves resources since the timestamp is stored only once. In addition, it also reduces the number of time-series or cardinality, thus reducing metadata size and reducing latency. QuestDB stores each column as a separate file and thus supports a huge number of columns in a table. TimeScale can currently only support 1600 columns while TDengine can currently only support 4096 columns. In the next big release of TDengine, TDengine will support as many columns as are needed without any performance degradation. In lots of scenarios, metrics are typically tied together. For e.g. the x, y and z coordinates of a GPS position are always tied together. In a smart power meter, current and voltage are always connected and it does not make sense to separate them. In DevOps, the inbound and outbound traffic volume are always measured at the same time and CPU and memory usage are always sampled at the same time. We should not need to separate them into two time-series. In some scenarios, collected metrics may change a lot and it may be hard to define a schema at the beginning. While single column is a good choice for flexibility, for the majority of scenarios such as GPS position, smart power meters, financial data and many others, the metrics are defined very clearly. In these cases multi-column is a better choice to save system resources and to reduce latency. For flexibility and performance, multi-column and single column model can be mixed together as is done in TDengine. Data Types Prometheus and OpenTSDB only support numeric data type while TDengine, TimeScale, InfluxDB and QuestDB supports numeric and many other data types. In some use cases, such as IT infrastructure monitoring, a numeric data type is good enough. In most other use cases, however, such as IoT and connected vehicles, a numeric data type is not enough. It requires Boolean, integer, and string data types among others. An advantage of using different data types for different metrics is that different compression algorithms can be used to enhance the compression ratio. Summary For developers who are more used to NoSQL models, the Tag Set model is quite easy to get started with since it does not require a schema to be defined. But this early simplicity can lead to complexity later in various ways, such as making tags more difficult. As we have seen, the query language is always proprietary and not standards-based like SQL. This leads to unnecessary learning costs and a lack of reusability. If the application requires more analytical features or more third-party tools, the relational data model is a better choice. We have also seen that the multi-column model can save system resources and reduce latency while the single-column model is more flexible to accommodate schema changes. The best practice for a growing IoT world is to combine multi-column and single-column together in the platform. As for data types, based on the scenario, it is usually quite easy to arrive at an answer to the question of whether support for more data types is better. First published here

Comparing Different Time-Series Databases

3 Key Questions You Need To Answer Tak, tok, trak, tok, tak, trak, taka, tak, tok, trak, tok, tak, trak, taka, tak… goes the sound of your keyboard as your fingers hit the keys like a chicken voraciously picking its food. You are under a lot of pressure and in a race to beat the looming deadline. But wait for a second, my friend! Before you commit that code and push it to the server deployment, ask yourself these questions: Is that piece of code optimized for scale? Space and Time complexities… Have you tested it in all possible ways you can? Happy paths as well as edge cases… How much work do I need to do when the next change (and deadline) comes around? A handful of files or a multitude of them… you say, “Hey, Emmanuel,”, “these are all nice and good, but my deadline is right in front of me”. Well, that true, but we know the downsides are real and can get messy. seems There is really no reason or excuse to push poor-quality code. You will later spend a lot more time later debugging or rewriting your code. Thanks for reading this article! Don’t forget to share with others.

3 Key Questions You Need To Answer Before You Push That Code

Do you feel intimidated when you see other programmers quickly navigate through hundreds of lines of code, make blazing fast edits or open multiple tabs during development and hardly touch their mouse or touch-pad ? It feels like you are watching a magician perform amazing feats and you instantly think she is born to code. You imagine that attempting such feat is out of your reach and would take you forever to catch up. Well, in this short guide, I will show you the website I built and help you learn that it will only take some daily practice and patience to be fluent with your IDE. I have been using VSCode for over a year now. When I’m working, I often switch from one operating system to another depending on the task at hand. I use MacOS primarily but have to perform some tasks on Ubuntu and Windows. On all these platforms, I enjoy using VSCode. To lookup or learn more VSCode shortcuts, I usually go to the official docs and check the pdfs for the OS I’m currently on. I really don’t like the idea of checking each documentation for Mac, Linux and Windows at different times. I find it pretty boring. A Better Reference I decided to create a single page website where I and anyone using VSCode on the major platforms could easily go to learn or reference these shortcuts. It took me about 3 days to finish it  as I have a full-time job and used my spare time to work on it. I also turned it into a ( Progressive Web Application ) so it works well offline and can be installed on your desktop and mobile. PWA Here is the live website: https://vscode-shortcuts.com/ The shortcuts are grouped into 11 main sections: General Basic Editing Multi-cursor and Selection Search and replace Rich languages editing Navigation Editor Management File Management Display Debug Integrated Terminal You can easily search within each of the sections to quickly find the shortcut you’re looking for. How cool is that! Best way to learn them The easiest way to learn the shortcuts is by . You simply determine you want to learn and then go through the list, pick one that helps ease or speed up your workflow and practice for about 10 to 20 mins. If you do this little exercise daily, it won’t be long and you are the others will be aspiring to be like. good old repetition what code magician What about those best X lists of shortcuts for Y? Those lists are great and I check them out sometimes too. However, you best know your workflow and context you are working with and therefore the most useful shortcuts that work well for you. Keep learning and don't forget to share. Thank you

How to Learn All VSCode Shortcuts on Mac, Linux and Windows

HackerNoon curated the internet's most cited 3M+ tech company news articles and blog posts about the 3k+ most valuable tech companies in 2022 and 2023. These stories were curated to power HackerNoon.com/Companies, where we update daily news on top technology companies like Microsoft, Google, and HuggingFace. This dataset is open sourced under the Creative Common License on HuggingFace as Tech Company News Data Dump. Please use this tech company news data freely for your project :-) How the tech companies were curated Our team made a list of the most valuable technology companies, and added companies as they started to trend in the news and on HackerNoon. The first one and half thousand were public companies based on market cap. Then as companies got mentioned in HackerNoon stories and performed well in our startup of the year voting, we added created tech company news pages for them. Once a tech company news page is created, our system curates and stores the trending news, articles and blog posts about that company based on our rules and prompts  that define what is a trending story. How the stories, articles and blog posts were sourced A combination of custom rules, prompts and conditions for relevance, specificity and trendiness using the Bing News API, the Brave News API, and the HackerNoon API. We drilled down industry match for each company, and heavily favored more trusted high ranking sites while also allowing for relevant lower ranking niche publishers. For each company, we surface the most relevant 10-20 stories on their main /company page (Microsoft as an example), and then feature the complete list of the company’s news, stories, mentions, articles and notable links in internet history on company-name/news (Google as an example). How this tech company news data is organized The columns are companyName, company URL, publishedAT, (story) url, title, featured image, and (meta) description. This follows how we organize data in our database. Every article is connected to at least one company. Some companies have more articles than other based on their share of voice, for example using the dataset viewer you can see Google has 99,152 results, 3M has 20,608 results, Adobe has 13,449 results, and NVIDIA has 19,811 results. Without even downloading the data, you can search for company or publication names in the dataset viewer, like NVIDIA pictured below: This dataset is open sourced under the Creative Common License on HuggingFace as Tech Company News Data Dump. Please use this tech company news data freely for your project :-)  You could quantify a company’s aggregate share of voice online, you could measure sentiment analysis of a company’s digital news coverage, you could train your model to predict what headlines will publish about what companies in future, or whatever other research about large tech companies and media coverage your heart desires. Check it out this open data here: https://huggingface.co/datasets/HackerNoon/tech-company-news-data-dump?embedable=true HackerNoon curated the internet's most cited 3M+ tech company news articles and blog posts about the 3k+ most valuable tech companies in 2022 and 2023. These stories were curated to power HackerNoon.com/Companies , where we update daily news on top technology companies like Microsoft , Google , and HuggingFace . This dataset is open sourced under the Creative Common License on HuggingFace as Tech Company News Data Dump . Please use this tech company news data freely for your project :-) HackerNoon HackerNoon HackerNoon.com/Companies HackerNoon.com/Companies Microsoft Microsoft Google Google HuggingFace HuggingFace HuggingFace as Tech Company News Data Dump How the tech companies were curated Our team made a list of the most valuable technology companies, and added companies as they started to trend in the news and on HackerNoon. The first one and half thousand were public companies based on market cap. Then as companies got mentioned in HackerNoon stories and performed well in our startup of the year voting , we added created tech company news pages for them. Once a tech company news page is created, our system curates and stores the trending news, articles and blog posts about that company based on our rules and prompts  that define what is a trending story. startup of the year voting tech company news page How the stories, articles and blog posts were sourced A combination of custom rules, prompts and conditions for relevance, specificity and trendiness using the Bing News API, the Brave News API, and the HackerNoon API. We drilled down industry match for each company, and heavily favored more trusted high ranking sites while also allowing for relevant lower ranking niche publishers. For each company, we surface the most relevant 10-20 stories on their main /company page ( Microsoft as an example ), and then feature the complete list of the company’s news, stories, mentions, articles and notable links in internet history on company-name/news ( Google as an example ). Microsoft as an example Google as an example How this tech company news data is organized The columns are companyName, company URL, publishedAT, (story) url, title, featured image, and (meta) description. This follows how we organize data in our database. Every article is connected to at least one company. Some companies have more articles than other based on their share of voice, for example using the dataset viewer you can see Google has 99,152 results , 3M has 20,608 results , Adobe has 13,449 results , and NVIDIA has 19,811 results . the dataset viewer Google has 99,152 results 3M has 20,608 results Adobe has 13,449 results NVIDIA has 19,811 results Without even downloading the data, you can search for company or publication names in the dataset viewer, like NVIDIA pictured below : NVIDIA pictured below This dataset is open sourced under the Creative Common License on HuggingFace as Tech Company News Data Dump . Please use this tech company news data freely for your project :-)  You could quantify a company’s aggregate share of voice online, you could measure sentiment analysis of a company’s digital news coverage, you could train your model to predict what headlines will publish about what companies in future, or whatever other research about large tech companies and media coverage your heart desires. HuggingFace as Tech Company News Data Dump Check it out this open data here: https://huggingface.co/datasets/HackerNoon/tech-company-news-data-dump?embedable=true https://huggingface.co/datasets/HackerNoon/tech-company-news-data-dump?embedable=true

Tech Company News Data Dump on HuggingFace: 3M Most Cited Posts About 3k Most Valued Tech Companies

টেক কোম্পানি নিউজ ডাটা ডাম্প অন হাগিংফেস: 7M সর্বাধিক উদ্ধৃত পোস্টগুলি 3k সর্বাধিক মূল্যবান প্রযুক্তি সংস্থাগুলি সম্পর্কে

Tech-Unternehmens-News-Datendump auf HuggingFace: 7 Millionen meistzitierte Beiträge über 3.000 am meisten geschätzte Technologieunternehmen

Volcado de datos de noticias de empresas tecnológicas en HuggingFace: 7 millones de publicaciones más citadas sobre las 3.000 empresas tecnológicas más valoradas

Dump de données d'actualités sur les entreprises technologiques sur HuggingFace : 7 millions d'articles les plus cités sur les 3 000 entreprises technologiques les plus appréciées

हगिंगफेस पर टेक कंपनी समाचार डेटा डंप: 3 हजार सबसे मूल्यवान टेक कंपनियों के बारे में 7M सर्वाधिक उद्धृत पोस्ट

HuggingFace のテクノロジー企業ニュース データ ダンプ: 最も価値のある 3,000 のテクノロジー企業に関する最も引用された 700 万件の投稿

기술 회사 뉴스 HuggingFace의 데이터 덤프: 가장 가치 있는 기술 회사 3,000개에 대한 가장 많이 인용된 게시물 700만 개

Despejo de dados de notícias de empresas de tecnologia no HuggingFace: 7 milhões de postagens mais citadas sobre 3 mil empresas de tecnologia mais valiosas

Свалка данных новостей технологических компаний на HuggingFace: 7 миллионов самых цитируемых публикаций о 3 тысячах самых ценных технологических компаний

Teknoloji Şirketi Haberleri HuggingFace'teki Veri Dökümü: 3 Bin En Değerli Teknoloji Şirketi Hakkında 7 Milyon En Çok Alıntı Yapılan Gönderi

Kết xuất dữ liệu tin tức công ty công nghệ trên HuggingFace: 7 triệu bài viết được trích dẫn nhiều nhất về 3k công ty công nghệ có giá trị nhất

HuggingFace 上的科技公司新闻数据转储：关于 3000 家最有价值科技公司的 700 万条被引用次数最多的帖子

Let me tell you how I came up with the idea of writing this article. “I woke up early last week, grabbed my cup of coffee after a quick shower, and opened up the window to watch the amazing sunrise. At that moment, I asked myself, Why don’t I write an article about B2B content ideation?” That’s it, Wait a second. You don’t seem to believe this story. Well, yeah, you are damn right. I made it up—it is a lie because first of all, I’m not fit for the 5 AM cold-shower club. Plus, there is no way on earth for any content marketer to come up with ideas just with imagination and even brainstorming. The pain of staring at an empty Google Doc with no clue of what to type down is what actually pushed me to write this piece. The idea for this article materialized as a result of me knowing that many content marketers: struggle to come up with content ideas that resonate put themselves in a loop of sharing the same 2015-fashion type of articles spend hours looking for analytics tools instead of jumping on a half an hour call with customers blindly copy competitors’ strategies and messaging search for sales-related-stats instead of recording a sales call think that TOFU content is all about tips and tactics think that content marketing is nothing but keyword research heavily rely on Gen AI and so on… So yeah, that’s what actually made me write this article. I can make this list longer, and I bet you also have something to add, but we won’t be giving a holistic look at the content marketing field in this article. We are going to talk about the way you should think before working on content - the function you should apply to ideate product-led topics and match the points by being intentional with your content. But hey… Why would you listen to me? I’m just a writer who is just getting a foot in the industry. B2B Yes, I have a decent grasp of knowledge on the topic, but it is what experts shared with me that brought on Aha! moment. I will be sharing all of that today. Let me step aside and introduce the experts to you: Lauren Lang, Director of Content and Brand Communications at Constructor 13+ years of experience in the content field LinkedIn- Here Tom Bangey, Senior Director of Content & Community at Juro 6+ years of experience in the content field LinkedIn- Here Content Lead at Eric Doty, Dock 8+ years of experience in the content field LinkedIn- Here Head of Content at Adima Timar, Userpilot 8+ years of experience in the content field LinkedIn- Here Content Marketing Manager at Tamara Omerovic, Databox 7+ years of experience in the content field LinkedIn- Here Former Content strategist at Elise Marion, system1 6+ years of experience in the content field LinkedIn- Here CEO& Founder at Vince Moreau, ScaleCrush 7+ years of experience in the content field LinkedIn- Here Enough of me, let’s see what experts have to say about their experience. Note: This article is nothing more than real-life experiences gathered for you to improve your thinking and help with planning your next steps. There are no tips. no tactics, and definitely no freaking hacks or shortcuts. Enjoy! On B2B SaaS Content Ideation What is your number 1# source of content ideas and how do you leverage it? Talk to your customers and sales prospects. All the tech tools and AI and competitor analysis can’t beat spending half an hour with a customer finding out about their problems at work. I would try and turn the notes from that conversation into thematic analysis, and also break down the projects and problems they talk about into disaggregated tasks that can be targeted individually or collectively in content. Tom@Juro: Sometimes it’s difficult for marketing to interact with customers for a variety of reasons. In that case, I’ve found the sales team to be my biggest source of content ideas, especially for product-focused content. They are the closest to understanding customer objections, pain points, and questions that influence the purchase decision, and they are used to thinking strategically about how to use whatever tools are at their disposal (including content) to close the deal. Lauren@Constructor: Here is a graphic, CMO&Founder at - shared with me once for an article, which is relevant to Lauren’s last insight: Andy Crestodina - Orbit Media The easiest source of content topics is starting with problems the product solves directly. For example, how to make a sales proposal, how to create a price quote, and why you should use a mutual action plan instead of a spreadsheet. Eric@Dock: Beyond those product-led sources, I also source ideas from: Topics frequently mentioned by guests on our podcast (it’s a good indicator of a trending topic that may not show up in keyword tools yet) Recorded sales calls, customer support tickets, and discussions with our founder Keyword research On Content ideation, Competitive analysis Does your competitive analysis affect your content ideation process? Yes, we analyze competitors and understand what topics they are strongest with and where they are lacking. We also look at content gaps and prioritize keywords based on buying intent, the possibility of showcasing the product in a contextual way, and pillars (we have months when we focus mostly on one or two pillars) Adina@Userpilot: Absolutely. Knowing the strategies and tactics that our competitors are using is critical to finding the places where we can differentiate ourselves in the market. In AI, there is a lot of smoke and mirrors, and there are even more tech buzzwords. Being able to educate customers and help them separate the signal from the noise is incredibly important, but first, you have to understand where your competition is coming from. Lauren@Constructor: Yes and no. Sometimes competitors have good ideas, sometimes they have terrible ideas. When they have good ideas, you can use them. When they don’t, discard their stuff. Vince@ScaleCrush: We do leverage competitive analysis, simply as a shortcut - if they’ve won some valuable traffic for a particular keyword, we can skip the keyword research and planning phase and just create content to target that keyword. Note of caution: a competitor ranking for a keyword is just evidence that they have traffic - not that the traffic itself has any value. Vanity traffic is vanity traffic, even if you take it from competitors! Tom@Juro: I don’t pay too much attention to competition in the ideation process itself. I look at the competition to prioritize my idea to-do list (i.e. what’s most unique). Eric@Dock: On SEO Content Ideation How do you incorporate SEO into your content ideation process? We have a highly focused and ROI strategy. Our blog is responsible for over 80% of the MRR so the focus is on producing BOFU content first and then choosing keywords that help build topical authority around our main pillars. Adina@Userpilot: SEO For any idea or keyword I’m toying with, I’ll normally spend some time in Ahrefs looking at related keywords. I’ll keep my eye out for underserved or low-difficulty keywords. Eric@Dock: But again, SEO plays a bigger factor in how we prioritize which ideas to work on rather than how we come up with ideas. I attach a handful of keywords to each content idea to come up with a rough SEO potential for each idea. I weigh that against other factors like relevance to our product, trendiness or timeliness, and overall just how excited we are about the topic. For our organic channels, we segment our content ideas longlist into high, mid, and low-intent keywords. If you only target high-intent then your website looks a bit spammy, so we mix it up a bit; and then the only logical thing to do is work through the backlog, prioritizing based on search volume, keyword difficulty, and funnel performance of similar pages. Tom@Juro: We do customer & market research, competitive analysis- and existing content audits. That gives us enough to determine overarching topics, which we then do keyword research for. Keyword research is the last step in the process Vince@ScaleCrush: :). We try to keep an eye on SEO, but in retail tech, we’re in a very saturated market where SEO simply doesn’t make sense as our primary distribution channel. We typically create content ideas based on customer needs and then do SEO research to find search terms with similar intent that we can incorporate into the pieces. But customer needs come first. Lauren@Constructor: On Content ideation, Team collaborations Do your teammates in Sales, Customer success, or product development work on content ideas with you, if yes, in what manner they do contribute? We typically collaborate via our preferred project management tool where the dedicated team simply shares their insights in the form of a task. We also have an initiative called “Customer Insights” where the Sales, Account Management, and Onboarding Teams share raw and verbatim insights on things customers say about their use cases, experience, and questions about using the product. Insights are captured through emails, chats, call snippets, and full calls and are available to anyone for product development, content ideation, and more. Tamara@Databox: I would also like to mention that Product Development teams at Databox not only share content ideas with us but also build additional features and tools like online calculators and performance scores to help marketing with lead generation activities directly. Yes — working cross-departmentally is so important in content ideation. You get to use the knowledge accumulated across the customer journey to identify any pain points that may be challenging your customers. You can also focus on important areas of your product that customers may need to be more comprehensively educated on. Using the topics gathered from my team, I use the cumulative knowledge to research keywords that align with those pain points and craft content based on that research. Elise@System1: Yes! Content creation is a team sport. When you’re dealing with enterprise software and a variety of user personas, it’s impossible for content marketing to get as granular as some of the other teams. But it’s in that granularity where the best ideas for content come from, so we often ask our product, sales, and CS teams for ideas and contributions. I’m very intentional about building a collaborative content culture. Lauren@Constructor: Yes, we do also leverage internal knowledge, but you need to take everything with a grain of salt. People have lots of assumptions about the market and sometimes they’re wrong. Vince@ScaleCrush: Our founder wears many of those hats, so most of our ideation takes place as ad hoc casual chats between the two of us. I also meet with our one account executive regularly just to chat about what content would be useful for him to do his job. For example, he might flag that he needs a case study for a particular customer vertical. Eric@Dock: Content strategy is derived from our company master plan and ICP, so there’s no risk that content isn’t aligned with other teams. However, if we’re targeting a specific persona we will sense-check the content by utilizing colleagues who talk to them all the time. For example, when we produce new contract templates for our website- part of what we do at Juro-, we’ll work with our colleagues in CS to make sure they fit with customers—for example, a is one of the most common contracts in Juro, according to customer data, which validates it as a priority for us. If no customers managed SOWs in Juro, it might not be worth ranking for. Tom@Juro: template statement of work On Content ideation, ( Not-to-do’s) What is your not-to-do thing while trying to come up with content ideas? If you need to ask ChatGPT for content ideas then perhaps you don’t know your ICP as well as you think you do! Generative AI can be enormously helpful in parts of the content workflow. Still, top-ranking organic content needs (by definition) to be in the top 0.1% of content, which means it probably can’t be written by a predictive model. Tom@Juro: Don’t blindly rely on keyword research or SEO tools during your content ideation process. The best SEO tool you can use to create powerful and engaging content is actually your brain. Your brain can comprehend the intent behind user search queries better than any tool and come up with creative ideas, unique perspectives, and compelling narratives that resonate with readers, which is a crucial aspect of SEO. Therefore avoid relying too heavily on SEO tools in a way that may stifle creativity or lead to a "copycat" mentality, where you mimic your competitors' content strategies without considering what truly sets your brand apart. Tamara@Databox: The biggest thing is to leave yourself time to come up with ideas. Once you’re on the content flywheel, it’s easy to get stuck in a heads-down production schedule where you never take time to lift your head up and look around for more creative ideas. Eric@Dock: From an SEO perspective, avoid the trap of trying to rank for high-volume, top-of-funnel keywords that don’t relate directly to your product for as long as you can (or at least early in your company’s lifecycle). Start with all the mid-funnel searches your product solves directly. They’ll be easier to rank for and better for lead generation. Too many thought leadership articles that might just bring a bit of traffic in the month but no conversions. Adina@Userpilot: Avoid posting content for the sake of posting it. Content should align with a strategy. Don’t start with keywords in mind - don’t look at search volume too much, and don’t write about something if you don’t think you have expertise. Vince@ScaleCrush: My company is an AI company, so I’m actually very bullish on AI. But I would advise against using ChatGPT to help you come up with original content. By its very nature, ChatGPT is going to rehash only what already exists, which is exactly what you likely shouldn’t be creating in most cases. Great content comes from innovation and creativity, from seeing and filling the gaps in what already exists. Treating content like a commodity will give you commodity content – and commodity content doesn’t stand out or drive conversions. Lauren@Constructor: The bottom line As I told you, no tips and tactics here. Your approach to content ideation is your own tips and tactics. Some articles out there on the SERPs will pull up some stats and facts and tell you to do this and that. although they might be right sometimes, it is none of their goddamn business, it’s yours, your product, and your audience, you decide what works better. There are no plans and standards in the content field anymore, everything is subjective. Rethink and adapt, rethink and adapt, rethink and adapt. And hey! If there is one thing to consider doing from this article, it is 100 percent, talking to your customers. Cheers

Mastering B2B Content Ideation: Insights from 7 Industry Experts

THE FABLE OF THE CICADA AND THE ANT

TDENGINE

tdengine.com

51-200 employees

Since 2017

COMPANY RANKING

TDENGINE

EVERGREEN INDEX #10700

Representing this company? Click here to claim and customize this page!

TDengine WIKI

Apply to get your Tech Company News Page live on HackerNoon.com today!

TDENGINE

tdengine.com

51-200 employees

Since 2017

COMPANY RANKING

TDENGINE

EVERGREEN INDEX #10700

RELATED COMPANIESRANK

STORIES ABOUT TDENGINE

Representing this company? Click here to claim and customize this page!

TDengine WIKI

Apply to get your Tech Company News Page live on HackerNoon.com today!