SCHOOL FUNCTION

Periyar Nagar, VallamThanjavur - 613 403, Tamil Nadu, India

Phone: +91 - 4362 - 264600 Fax: +91- 4362 - 264660
Email: headmca@pmu.edu Web: www. pmu.edu

Department of Computer Science & Applications

Real Time Evaluation Report

Course : MCA Year : II Semester : IV Regulation : 2019
Subject Code : YCAE42
Subject : INTERNET PROTOCALS
Submitted by
Name : SRIRANGADEVI.T
Reg.no : 118011452172

Examiners Content Presentation Depth Communication Responsive Marks

organization of & Language to audience
content
(5) (5) (5) (5) (5) (25)
Internal
External
Total(50)
Total(100)

Signature of Signature of
Internal Examiner External Examiner

An ISO 9001:2008 Certified Institution

 DEPARTMENT OFCOMPUTER SCIENCE AND
APPLICATIONS

Periyar Nagar, VallamThanjavur - 613 403, Tamil Nadu, India

Phone: +91 - 4362 - 264600 Fax: +91- 4362 - 264660
Email: headmca@pmu.edu Web: www. pmu.edu

Bonafide Certificate

Certified To Be Bonafide Record Of Work Done By Mr/Ms. SRIRANGADEVI.T Reg.No.

118011452172 Of MCA Degree IV Semester Mid Semester Real Time Evaluation In The

“YCAE42– INTERNET PROTOCALS “ During The Year 2018-2019.

Course Teacher Head of the Department

ISO 9001:2008 Certified Institution

 TIME SERIES DATA BASE

INTRODUCTION

 A Time Series Database (TSDB) is a database optimized for time-stamped or time series
data. Time series data are simply measurements or events that are tracked, monitored,
downsampled, and aggregated over time. This could be server metrics, application
performance monitoring, network data, sensor data, events, clicks, trades in a market, and
many other types of analytics data.
 A Time Series Database is built specifically for handling metrics and events or
measurements that are time-stamped. A TSDB is optimized for measuring change over
time. Properties that make time series data very different than other data workloads are
data lifecycle management, summarization, and large range scans of many records.

 time series database (TSDB) is a software system that is optimized for handling time
series data, arrays of numbers indexed by time (a datetime or a datetime range). In some
fields these time series are called profiles, curves, or traces.

 Ideally, repositories of time series are natively implemented using specialized database
algorithms. However, it is possible to store time series as binary large objects (BLOBs) in
a relational database or by using a VLDB approach coupled with a pure star
schema. Efficiency is often improved if time is treated as a discrete quantity rather than
as a continuous mathematical dimension.

 A time series database allows users to create, enumerate, update and destroy various time
series and organize them. The server often supports a number of basic calculations that
work on a series as a whole, such as multiplying, adding, or otherwise combining various
time series into a new time series.
 They can also filter on arbitrary patterns such as time ranges, low value filters, high value
filters, or even have the values of one series filter another.Some TSDBs also build in
additional statistical functions that are targeted to time series data.
EXAMBLE

Select gold price*gold volume

The TSDB would join the two series 'gold_price' and 'gold_volume' based on the
overlapping areas of time for each, multiply the values where they intersect, and then output a
single composite time series.
TSDBs often allow users to manage a repository of filters or masks that specify in some
way a pattern. In this way, one can readily assemble time series data. Assuming such a filter
exists, one might hypothetically write
Select onpeak(cellphoneusage)
which would extract out the time series of cellphoneusage that only intersects that of
'onpeak'.
This syntactical simplicity drives the appeal of the TSDB. For example, a simple utility
bill might be implemented using a query such as:

Select max(onpeak(powerusagekw)) * demand_charge;

Select max(onpeak(powerusagekw)) * energy_charge;

LIST OF TIME SERIES DATABASES

Name License Language References

[5]
Atlas Apache License 2.0[4] Java

[5]
Cube Apache License 2.0[6] JavaScript

[5]
DalmatinerDB MIT[7] Erlang

[5]
Druid Apache License 2.0 Java

[5]
eXtremeDB Commercial SQL, Python, C / C++, Java, and C#
WHY IS A TIME SERIES DATABASE IMPORTANT NOW?

 Time Series Databases are not new, but the first-generation Time Series Databases were
primarily focused on looking at financial data, the volatility of stock trading, and systems
built to solve trading.
 Yet the fundamental conditions of computing have changed dramatically over the last
decade. Everything has become compartmentalized.
 Monolithic mainframes have vanished, replaced by serverless servers, microservers, and
containers.
 Today, everything that can be a component is a component. In addition, we are
witnessing the instrumentation of every available surface in the material world—streets,
cars, factories, power grids, ice caps, satellites, clothing, phones, microwaves, milk
containers, planets, human bodies.
 Everything has, or will have, a sensor. So now, everything inside and outside the
company is emitting a relentless stream of metrics and events or time series data.This
means that the underlying platforms need to evolve to support these new workloads—
more data points, more data sources, more monitoring, more controls.
 What we’re witnessing, and what the times demand, is a paradigmatic shift in how we
approach our data infrastructure and how we approach building, monitoring, controlling,
and managing systems. What we need is a modern TSDB.
WHEN TO USE A TIME SERIES DATABASE

Lots of companies and individuals store their time series data in other types of databases
(relational, noSQL) successfully. If you’re one of those, you’re happy, and you have no current
issues, far be it from me to demand you change. You do you.

However, there are definite benefits to using a database designed for your time series data.

Scalability
 Scalability is one of those magical words that we hear often and is used
correctly sometimes. The general problem with time series and scale outside of a Time
Series Database is this: if Skynosaur flies for 1,500 hours (the minimum number of hours
for a commercial pilot’s license), we’ve already reached over a million data points for
one device.
 The makers of Skynosaur (Skynosaurus Rex, Inc.) could have thousands of devices
sending data home. Querying by timestamp would involve millions of rows of data in a
relational database.
 People often claim that SQL databases don’t scale well while NoSQL databases do, but it
was easier for me to understand in terms of ACID versus BASE. To unfairly summarize,
ACID-compliant databases are concerned with guaranteeing validity — data should be
atomic, consistent, isolated and durable.

Usability
 If all of our data lived in a secure, durable black box, we could breathe easy. But how we
access the data can be just as important as its storage. Every database has its query
language, designed to access the contents as efficiently as possible.
 Keep that in mind because as we mentioned earlier, time series data is special. It’s a
double rainbow with a timestamp.
Trade-offs
 Database architecture is about trade-offs and priorities. Do you need speed or accuracy or
volume or predefined schemas? The proof is in the benchmarks. Measure everything.
 Don’t choose a tool or a product—choose a solution to your problem. Specialty tools are
made for special problems, so time series databases are optimized for time series
problem.

THOUGHTS ON TIME-SERIES DATABASES

Preetam "recently" blogged about catena, a time-series metric store. There was another
blog post about benchmarking boltdb by a Fog Creek engineer, also looking to write a time
series database. This is something of a pattern in the Go community, which already
boasts seriesly, InfluxDB, and prometheus; there are almost certainly others.

Time series data has been de rigueur at least since the Etsy's seminal blog post on StatsD,
though in reality that was just an inflection point. Time series modeling and graphing predates
computer systems, but they have been a popular way of tracking and visualizing systems and
networking data since at least the early 90s with MRTG.

A few factors are converging now to make these kinds of systems more important: "Big
Data" is getting much, much bigger; virtualization and containerization has increased the number
of independent "nodes" for a typical distributed application; and the economies of the cloud have
put the brakes on the types of performance increases typically attributed to "Moore's Law."

For a primer on this subject, please read Baron's Time-Series Database Requirements.
There's a reason that most other recent articles cite it; it contains a brief but complete description
of the problem, the requirements for many large-scale time-series users, and some surprises for
the uninitiated. Some of the implications that are implicit in these requirements but perhaps not
obvious to onlookers:

 users of these systems over-collect to enable post-facto investigation into events/outages

 because of this there is generally a ton of data, 99% of which is likely neverread
 the number of distinct timeseries can be very large
  timeseries can range from being very dense (every second or more) to verysparse (a report
run once a day/week/month)
 the expectation is that reads on recent data is very low latency ("real time")

 writes are inherently difficult to batch; If you are doing 1mm points/sec, chances
are none of those are to the same series (translate this as file/row/column/key, depending
on your data store)
 reads must be efficient; most useful charts involve joins across dozens if not hundreds of
series

data is collected at high resolution (a second or less) but eventually displayed at low resolution
(minutes or more); despite this, these reads must be fast and accurate.

TIME SERIES DATA IS AN OLD IDEA

 It may surprise you to know that one of the great examples of the advantages to be
reaped from collecting data as a time series—and doing it as a crowdsourced, open
source, big data project—comes from the mid-19th century.
 The story starts with a sailor named Matthew Fontaine Maury, who came to be known
as the Pathfinder of the Seas. When a leg injury forced him to quit ocean voyages in his
thirties, he turned to scientific research in meteorology, astronomy, oceanography, and
cartography, and a very extensive bit of whale watching, too.
 Ship’s captains and science officers had long been in the habit of keeping detailed
logbooks during their voyages.
 Careful entries included the date and often the time of various measurements, such as
how many knots the ship was traveling, calculations of latitude and longitude on
specific days, and observations of ocean conditions, wildlife, weather, and more.
CONCLUSION

A time series database allows users to create, enumerate, update and destroy
various time series and organize them. The server often supports a number of basic
calculations that work on a series as a whole, such as multiplying, adding, or otherwise
combining various time series into a new time series.

REFERENCES

www.wikipedia.com

www.tutorialpoint.com

www.edupristin.com